perm filename W88[JNK,JMC] blob
sn#855038 filedate 1988-03-25 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00716 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00110 00002 ∂20-Jul-87 1710 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com WEDNESDAY PLANLUNCH -- THIS WEDNESDAY -- Toyoaki Nishida
C00113 00003 ∂21-Jul-87 1253 edsel!bhopal!jonl@labrea.stanford.edu LOOP "Blurb & Crib Sheet"
C00138 00004 ∂21-Jul-87 1253 edsel!bhopal!jonl@labrea.stanford.edu "Iteration" activity
C00143 00005 ∂21-Jul-87 1908 SCHAFFER@Sushi.Stanford.EDU Next AFLB
C00147 00006 ∂22-Jul-87 0741 FAHLMAN@C.CS.CMU.EDU Iteration proposals
C00149 00007 ∂22-Jul-87 0746 RICHARDSON@Score.Stanford.EDU SOE Directory
C00151 00008 ∂22-Jul-87 0924 DEWERK@Score.Stanford.EDU [Stuart Reges <REGES@Score.Stanford.EDU>: summer camp]
C00154 00009 ∂23-Jul-87 0944 edsel!bhopal!jonl@labrea.stanford.edu Iteration proposals
C00157 00010 ∂23-Jul-87 1040 NILSSON@Score.Stanford.EDU space plans
C00163 00011 ∂23-Jul-87 1138 ullman@navajo.stanford.edu papers received
C00165 00012 ∂23-Jul-87 1449 NILSSON@Score.Stanford.EDU soe actions
C00168 00013 ∂23-Jul-87 1723 TAJNAI@score.stanford.edu The Forum Meets its One Megabuck Goal!!
C00170 00014 ∂24-Jul-87 1053 ULLMAN@score.stanford.edu [Stefano Ceri <CER@Score.Stanford.EDU>: EDBT call for papers]
C00180 00015 ∂24-Jul-87 1904 @score.stanford.edu:SUBRAMANIAN@SUMEX-AIM.STANFORD.EDU Request for nominations
C00183 00016 ∂25-Jul-87 1355 NILSSON@Score.Stanford.EDU Research Centers
C00186 00017 ∂27-Jul-87 0126 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #48
C00203 00018 ∂28-Jul-87 0122 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #49
C00215 00019 ∂28-Jul-87 1914 SCHAFFER@Sushi.Stanford.EDU Last 2 TheoryNet Messages
C00224 00020 ∂28-Jul-87 1922 SCHAFFER@Sushi.Stanford.EDU Next AFLB
C00229 00021 ∂29-Jul-87 0011 MAVARDI%WEIZMANN.BITNET@forsythe.stanford.edu Call
C00236 00022 ∂29-Jul-87 0141 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #50
C00248 00023 ∂29-Jul-87 1320 OKUNO@SUMEX-AIM.STANFORD.EDU Explorer during my vacation (Aug. 1 ~ 23)
C00250 00024 ∂29-Jul-87 1420 BSCOTT@Score.Stanford.EDU Yvette Sloan
C00252 00025 ∂29-Jul-87 1450 AAAI-OFFICE@SUMEX-AIM.STANFORD.EDU [AAAI <AAAI-OFFICE@SUMEX-AIM.STANFORD.EDU>: Committee involvement]
C00255 00026 ∂30-Jul-87 1416 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #51
C00265 00027 ∂31-Jul-87 1243 WALDINGER@WARBUCKS.AI.SRI.COM Journal of Automated Reasoning
C00272 00028 ∂31-Jul-87 1446 ullman@navajo.stanford.edu Referee(s) wanted
C00274 00029 ∂31-Jul-87 1619 @Score.Stanford.EDU:ISMUMICK@Sushi.Stanford.EDU We need a host for New Student Brunch
C00277 00030 ∂02-Aug-87 1521 NILSSON@Score.Stanford.EDU conferences
C00278 00031 ∂03-Aug-87 0120 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #53
C00296 00032 ∂03-Aug-87 0319 @Sushi.Stanford.EDU:THEORYNT%YKTVMZ.BITNET@forsythe.stanford.edu STOC CALL FOR PAPERS
C00302 00033 ∂03-Aug-87 0953 ULLMAN@score.stanford.edu [<KERSCH%GMUVAX.BITNET@forsythe.stanford.edu>: Call for Papers: Expert Database Systems Conference]
C00316 00034 ∂03-Aug-87 1052 NILSSON@Score.Stanford.EDU SOE Retreat
C00318 00035 ∂03-Aug-87 1445 RICHARDSON@Score.Stanford.EDU CRAY
C00319 00036 ∂03-Aug-87 1520 @Sushi.Stanford.EDU,@Score.Stanford.EDU:gaifman@navajo.stanford.edu NL=c0-NL
C00321 00037 ∂03-Aug-87 1546 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com PLANLUNCH THIS WEDNESDAY --- Dan Weld
C00325 00038 ∂03-Aug-87 1616 @Score.Stanford.EDU:LES@SAIL.STANFORD.EDU Welcome Jim Ball
C00327 00039 ∂04-Aug-87 0151 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #54
C00338 00040 ∂04-Aug-87 1034 JSW Ignorant now running Genera 7.1
C00345 00041 ∂04-Aug-87 2226 SCHAFFER@Sushi.Stanford.EDU Next AFLB
C00348 00042 con-Aug-87 1037 BSCOTT@Score.Stanford.EDU Audit--Expenditure Statements
C00350 00043 ∂05-Aug-87 1213 @Sushi.Stanford.EDU:THEORYNT%YKTVMZ.BITNET@forsythe.stanford.edu Structures 88 Call for Papers
C00356 00044 ∂05-Aug-87 1936 @Score.Stanford.EDU,@RELAY.CS.NET:golub@research.att.com Re: Audit--Expenditure Statements
C00358 00045 ∂06-Aug-87 0300 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #56
C00429 00046 ∂06-Aug-87 1108 BERGMAN@Score.Stanford.EDU RAships
C00431 00047 ∂06-Aug-87 1156 NILSSON@Score.Stanford.EDU committees
C00440 00048 ∂06-Aug-87 2003 @Score.Stanford.EDU:ZHULU@Sushi.Stanford.EDU short term lodging for new students
C00443 00049 ∂10-Aug-87 0116 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #57
C00453 00050 ∂10-Aug-87 0543 @Sushi.Stanford.EDU:THEORYNT%YKTVMZ.BITNET@forsythe.stanford.edu Logic In Computer Science (LICS) Call for Papers
C00460 00051 ∂10-Aug-87 1219 PAPA@score.stanford.edu Chain Rule Paper
C00462 00052 ∂10-Aug-87 1441 LES Facilities Committee Special Meeting
C00466 00053 ∂10-Aug-87 1448 @Sushi.Stanford.EDU:PAPA@Score.Stanford.EDU Address
C00467 00054 ∂10-Aug-87 1718 RINDFLEISCH@SUMEX-AIM.STANFORD.EDU Re: Facilities Committee Special Meeting
C00470 00055 ∂11-Aug-87 1532 TOM@Score.Stanford.EDU Re: Facilities Committee Special Meeting
C00474 00056 ∂11-Aug-87 1627 PALLAS@Sushi.Stanford.EDU Re: Facilities Committee Special Meeting
C00480 00057 ∂11-Aug-87 2216 REGES@Score.Stanford.EDU more thoughts
C00484 00058 ∂12-Aug-87 1016 TOM@Score.Stanford.EDU power shut-down dates
C00486 00059 ∂12-Aug-87 2318 TAJNAI@Score.Stanford.EDU Special Seminar, Friday, Aug. 14, 11 a.m., CIS
C00488 00060 ∂13-Aug-87 2028 TAJNAI@score.stanford.edu TG for a Million Party
C00490 00061 ∂14-Aug-87 0803 @HAL.CAD.MCC.COM:Loeffler@MCC.COM Windows Subcommittee
C00492 00062 ∂17-Aug-87 1217 @Sushi.Stanford.EDU:jan%ruuinfvax.uucp@forsythe.stanford.edu Copies of proceedings of 2nd Int. Workshop on Distributed Algorithms
C00495 00063 ∂18-Aug-87 1148 NILSSON@Score.Stanford.EDU kudos for Chuck Bigelow
C00497 00064 ∂18-Aug-87 1237 JSW Gang-of-Four is sick
C00498 00065 ∂18-Aug-87 1313 @Score.Stanford.EDU:FEIGENBAUM@SUMEX-AIM.STANFORD.EDU Japan, anyone?
C00500 00066 ∂18-Aug-87 1419 NILSSON@Score.Stanford.EDU [reid@decwrl.DEC.COM (Brian Reid): Re: kudos for Chuck Bigelow]
C00503 00067 ∂18-Aug-87 1518 TOM@Score.Stanford.EDU imagen/maple
C00504 00068 ∂18-Aug-87 1652 GILBERTSON@Score.Stanford.EDU 87-88 Parking Permit - Dept Delivery
C00506 00069 ∂18-Aug-87 2006 SCHAFFER@Sushi.Stanford.EDU Next AFLB
C00510 00070 ∂19-Aug-87 1006 TAJNAI@Score.Stanford.EDU photos for brochure
C00511 00071 ∂19-Aug-87 1516 TOM@Score.Stanford.EDU [Thomas Dienstbier <TOM@Score.Stanford.EDU>: 87000 purchase/or not]
C00514 00072 ∂20-Aug-87 1515 SCHAFFER@Sushi.Stanford.EDU Special AFLB
C00516 00073 ∂20-Aug-87 1622 LES Facilities Committee Meetings
C00520 00074 ∂21-Aug-87 0618 @Sushi.Stanford.EDU:craig%computer-science.strathclyde.ac.uk@forsythe.stanford.edu Complexity of communicating processors
C00523 00075 ∂21-Aug-87 0937 TAJNAI@score.stanford.edu 2 Apple laserwriters stolen from ERL
C00525 00076 ∂21-Aug-87 1237 @Sushi.Stanford.EDU:steve%hubcap.clemson.edu@forsythe.stanford.edu Announcing expanded subject interest on "comp.hypercube"
C00528 00077 ∂21-Aug-87 1246 @Sushi.Stanford.EDU:shebs%cs.utah.edu@forsythe.stanford.edu Clustering to Minimize Window Motion
C00532 00078 ∂21-Aug-87 1337 TAJNAI@Score.Stanford.EDU New Forum Membership Status
C00534 00079 ∂22-Aug-87 1750 PALLAS@Sushi.Stanford.EDU Re: Facilities Committee Meetings
C00543 00080 ∂24-Aug-87 0913 hitson@pescadero.stanford.edu Re: Facilities Committee Meetings
C00552 00081 ∂25-Aug-87 1510 ullman@navajo.stanford.edu papers received
C00554 00082 ∂25-Aug-87 1716 LIBRARY@Score.Stanford.EDU Math/CS Library Material Access for Sept.
C00558 00083 ∂25-Aug-87 1801 SCHAFFER@Sushi.Stanford.EDU Next AFLB
C00563 00084 ∂25-Aug-87 1816 TAJNAI@score.stanford.edu CSD t-shirts and Proceedings from Reunion/Symposium
C00565 00085 ∂25-Aug-87 2020 LES Facilities Committee Meeting
C00578 00086 ∂25-Aug-87 2032 REGES@Score.Stanford.EDU a small matter of $20K
C00580 00087 ∂26-Aug-87 0917 @WARBUCKS.AI.SRI.COM,@malibu:olender@malibu.ai.sri.com PLANLUNCH / MONDAY AUGUST 31, 1987.
C00584 00088 ∂26-Aug-87 0948 @WARBUCKS.AI.SRI.COM,@malibu:olender@malibu.ai.sri.com PLANLUNCH / MONDAY AUGUST 31, 1987.
C00588 00089 ∂26-Aug-87 1206 hitson@gregorio.stanford.edu Re: Facilities Committee Meeting
C00592 00090 ∂27-Aug-87 1650 TAJNAI@Score.Stanford.EDU Sunrise Club Important Announcement
C00594 00091 ∂31-Aug-87 0924 @WARBUCKS.AI.SRI.COM,@BISHOP.AI.SRI.COM:Pollack@AI.SRI.COM PLANLUNCH reminder
C00598 00092 ∂31-Aug-87 1031 @Sushi.Stanford.EDU:sadler%Buckner-EMH.arpa@forsythe.stanford.edu Rqst for help from readers
C00603 00093 ∂31-Aug-87 1103 TAJNAI@Score.Stanford.EDU $25K from NTT - anyone claim it?
C00604 00094 ∂01-Sep-87 1245 @Score.Stanford.EDU:SMC@SAIL.STANFORD.EDU Phone numbers for John McCarthy
C00605 00095 ∂01-Sep-87 1554 @Score.Stanford.EDU:SMC@SAIL.STANFORD.EDU McCarthy Phone #s
C00606 00096 ∂02-Sep-87 0945 EMMA@CSLI.Stanford.EDU CSLI Talk
C00609 00097 ∂02-Sep-87 1013 @Sushi.Stanford.EDU:GALIL%cs.columbia.edu@forsythe.stanford.edu Warning: The Tenth Columbia University Theory Day
C00612 00098 ∂02-Sep-87 1024 @Sushi.Stanford.EDU:lory%CAF.MIT.EDU@forsythe.stanford.edu Call for Papers
C00620 00099 ∂02-Sep-87 1052 @Score.Stanford.EDU:JHILL@Sierra.Stanford.EDU Faculty Directory
C00622 00100 ∂03-Sep-87 1739 NILSSON@Score.Stanford.EDU Winograd Award
C00624 00101 ∂04-Sep-87 1040 @WARBUCKS.AI.SRI.COM,@malibu:olender@malibu.ai.sri.com
C00628 00102 ∂04-Sep-87 1108 NILSSON@Score.Stanford.EDU Prize
C00630 00103 ∂04-Sep-87 1130 @Score.Stanford.EDU:FEIGENBAUM@SUMEX-AIM.STANFORD.EDU Re: Prize
C00632 00104 ∂04-Sep-87 1250 REGES@Score.Stanford.EDU TA assignments
C00634 00105 ∂04-Sep-87 1317 NILSSON@Score.Stanford.EDU libraries
C00639 00106 ∂04-Sep-87 1328 ENGELMORE@SUMEX-AIM.STANFORD.EDU The next DARPA workshop
C00641 00107 ∂04-Sep-87 1628 FEIGENBAUM@SUMEX-AIM.STANFORD.EDU Re: The next DARPA workshop
C00642 00108 ∂04-Sep-87 2240 @Score.Stanford.EDU:cheriton@pescadero.Stanford.EDU Re: libraries
C00645 00109 ∂06-Sep-87 1227 NILSSON@Score.Stanford.EDU Apple
C00647 00110 ∂08-Sep-87 0925 BSCOTT@Score.Stanford.EDU Personal Phone Calls
C00649 00111 ∂08-Sep-87 1251 TOM@Score.Stanford.EDU Campus wide power shut down
C00651 00112 ∂08-Sep-87 1635 SLOAN@Score.Stanford.EDU Sharon Hemenway
C00653 00113 ∂08-Sep-87 2106 @WARBUCKS.AI.SRI.COM,@malibu:olender@malibu.ai.sri.com [olender: TALK BY LYNDON WHILE / IMPERIAL COLLEGE, LONDON.]
C00657 00114 ∂09-Sep-87 1027 FEIGENBAUM@SUMEX-AIM.STANFORD.EDU funny slogan
C00658 00115 ∂09-Sep-87 1033 RINDFLEISCH@SUMEX-AIM.STANFORD.EDU Re: funny slogan
C00659 00116 ∂09-Sep-87 1118 CRISPIN@SUMEX-AIM.STANFORD.EDU re: funny slogan
C00660 00117 ∂09-Sep-87 1148 ENGELMORE@SUMEX-AIM.STANFORD.EDU re: funny slogan
C00661 00118 ∂10-Sep-87 0936 RICHARDSON@Score.Stanford.EDU Faculty Meeting
C00663 00119 ∂11-Sep-87 1019 @Sushi.Stanford.EDU:siri%imag.uucp%mcvax@forsythe.stanford.edu ACM-SIGIR88
C00673 00120 ∂11-Sep-87 1201 @Score.Stanford.EDU:EJM@Sierra.Stanford.EDU Apple
C00674 00121 ∂11-Sep-87 1409 @Sushi.Stanford.EDU:GALIL%cs.columbia.edu@forsythe.stanford.edu The Tenth Columbia University Theory Day
C00677 00122 ∂11-Sep-87 1419 @Sushi.Stanford.EDU:chazelle%Princeton.EDU@forsythe.stanford.edu call for papers
C00683 00123 ∂11-Sep-87 1458 ullman@nimbin.stanford.edu
C00690 00124 ∂12-Sep-87 1644 @Score.Stanford.EDU:NOWICK@Sushi.Stanford.EDU Invitation to New Student Brunch
C00694 00125 ∂14-Sep-87 0123 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #58
C00703 00126 ∂15-Sep-87 0152 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #59
C00723 00127 ∂15-Sep-87 0424 MATHIS@ADA20.ISI.EDU report on ISO NWI and SC22 meeting
C00729 00128 ∂15-Sep-87 0744 @Sushi.Stanford.EDU:brassard%cwi.nl@forsythe.stanford.edu For Number Theory Net
C00731 00129 ∂15-Sep-87 0857 @Sushi.Stanford.EDU:steve%hubcap.clemson.edu@forsythe.stanford.edu Request for suggestions in developing theory course
C00734 00130 ∂15-Sep-87 0929 dcm%hpfclp@hplabs.HP.COM October X3J13 meeting
C00749 00131 ∂16-Sep-87 0102 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #60
C00753 00132 ∂16-Sep-87 0920 TOM@score.stanford.edu campus power shutdown ll
C00756 00133 ∂16-Sep-87 1145 dcm%hpfclp@hplabs.HP.COM November X3J13 meeting
C00770 00134 ∂16-Sep-87 1748 SLOAN@score.stanford.edu 1987-88 Faculty Staff Directory
C00772 00135 ∂16-Sep-87 1818 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com NEXT WEEK'S PLANLUNCH -- Sanjay Mittal
C00778 00136 ∂17-Sep-87 0834 TAJNAI@score.stanford.edu Reminder! Sunrise Club Breakfast Tuesday, 9/22
C00780 00137 ∂17-Sep-87 1624 CBARSALOU@Score.Stanford.EDU Dr. Lawvere's visit: talks
C00783 00138 ∂17-Sep-87 2229 @Sushi.Stanford.EDU:ashok%ibm.com@forsythe.stanford.edu FOCS 1987 registration and program
C00809 00139 ∂18-Sep-87 1108 GANGOLLI@Sushi.Stanford.EDU Lectures on Sieves
C00811 00140 ∂18-Sep-87 1222 TAJNAI@score.stanford.edu Need Quotes for the Brochure
C00813 00141 ∂18-Sep-87 1224 CBARSALOU@Score.Stanford.EDU Lawvere's visit: Talks next week
C00816 00142 ∂18-Sep-87 1241 @Sushi.Stanford.EDU:CBARSALOU@Score.Stanford.EDU Lawvere's visit: Talks next week
C00820 00143 ∂18-Sep-87 1402 @Sushi.Stanford.EDU:PHY@SAIL.STANFORD.EDU
C00822 00144 ∂20-Sep-87 2049 BARWISE@CSLI.Stanford.EDU Mail problems
C00824 00145 ∂20-Sep-87 2209 LANSKY@WARBUCKS.AI.SRI.COM REMINDER -- MONDAY PLANLUNCh
C00825 00146 ∂21-Sep-87 0125 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #61
C00834 00147 ∂21-Sep-87 1917 NILSSON@score.stanford.edu Tues lunches
C00837 00148 ∂21-Sep-87 2311 @Sushi.Stanford.EDU:steve%hubcap.clemson.edu@forsythe.stanford.edu Minimal number of states for finite state machine
C00840 00149 ∂22-Sep-87 0133 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #62
C00858 00150 ∂22-Sep-87 1152 TAJNAI@score.stanford.edu ANy work being done in....
C00860 00151 ∂23-Sep-87 0127 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #63
C00874 00152 ∂23-Sep-87 0849 BARWISE@CSLI.Stanford.EDU Missing mail
C00876 00153 ∂23-Sep-87 0856 BARWISE@CSLI.Stanford.EDU New microcomputer program course
C00882 00154 ∂23-Sep-87 1000 OKUNO@SUMEX-AIM.STANFORD.EDU [linton@lurch.stanford.edu (Mark Linton): next Bay Area Systems Seminar]
C00897 00155 ∂23-Sep-87 1643 TAJNAI@score.stanford.edu still need pithy quotes
C00899 00156 ∂24-Sep-87 0142 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #64
C00921 00157 ∂24-Sep-87 0312 @RELAY.CS.NET:yuasa%kurims.kurims.kyoto-u.junet@UTOKYO-RELAY.CSNET Japanese Activities toward Lisp Standardization
C00929 00158 ∂24-Sep-87 1204 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Seminars
C00933 00159 ∂25-Sep-87 1029 ullman@navajo.stanford.edu paper received
C00934 00160 ∂25-Sep-87 1106 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #65
C00972 00161 ∂25-Sep-87 1517 @score.stanford.edu:WALESON@SUMEX-AIM.STANFORD.EDU KSL OPEN HOUSE
C00974 00162 ∂25-Sep-87 1719 @score.stanford.edu:WALESON@SUMEX-AIM.STANFORD.EDU KSL OPEN HOUSE
C00976 00163 ∂25-Sep-87 1730 NILSSON@score.stanford.edu faculty mtg
C00979 00164 ∂28-Sep-87 0135 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #67
C00997 00165 ∂28-Sep-87 0758 @Sushi.Stanford.EDU:gatech!hubcap!steve%mcnc.org@forsythe.stanford.edu Re: Minimal number of states for finite state machine
C01001 00166 ∂28-Sep-87 0813 @Sushi.Stanford.EDU:steve%hubcap.clemson.edu@forsythe.stanford.edu Clemson Mini Conference in Discrete Mathematics
C01005 00167 ∂28-Sep-87 0826 @Sushi.Stanford.EDU:RIPBC%CUNYVM.BITNET@forsythe.stanford.edu Seminar in Applications of Logic to Computer Science
C01008 00168 ∂28-Sep-87 0848 GRAD-ADMIN@score.stanford.edu Research Mentor Information
C01017 00169 ∂28-Sep-87 0934 BARWISE@CSLI.Stanford.EDU Newsletter
C01031 00170 ∂28-Sep-87 1346 @Sushi.Stanford.EDU:johnh@src.DEC.COM Computational Geometry Seminar Announcement
C01034 00171 ∂28-Sep-87 1640 RICHARDSON@score.stanford.edu Lunch/Meeting
C01036 00172 ∂28-Sep-87 1838 GANGOLLI@Sushi.Stanford.EDU Next two AFLB talks
C01039 00173 ∂29-Sep-87 0341 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #68
C01065 00174 ∂29-Sep-87 1502 KUDER@CSLI.Stanford.EDU Oct 12 and l5
C01067 00175 ∂29-Sep-87 1519 @score.stanford.edu:MUMICK@Sushi.Stanford.EDU CSD Reception
C01069 00176 ∂29-Sep-87 1742 @score.stanford.edu:LES@SAIL.STANFORD.EDU CS 300 Department Lecture Series
C01071 00177 ∂29-Sep-87 1942 @score.stanford.edu:dill@amadeus.stanford.edu Re: CS 300 Department Lecture Series
C01073 00178 ∂29-Sep-87 1951 HADDAD@Sushi.Stanford.EDU BATS: call for speakers.
C01075 00179 ∂30-Sep-87 0009 SF@CSLI.Stanford.EDU Seminar in Logic at Stanford
C01078 00180 ∂30-Sep-87 0157 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #69
C01086 00181 ∂30-Sep-87 1101 @score.stanford.edu:ball@navajo.stanford.edu CSD-CF RATES
C01092 00182 ∂30-Sep-87 1631 @score.stanford.edu:MUMICK@Sushi.Stanford.EDU CSD Reception
C01094 00183 ∂30-Sep-87 1827 OKUNO@SUMEX-AIM.STANFORD.EDU Russ's talk at Parc
C01096 00184 ∂01-Oct-87 0228 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #70
C01124 00185 ∂01-Oct-87 0341 DELAGI@SUMEX-AIM.STANFORD.EDU Re: Russ's talk at Parc
C01126 00186 ∂01-Oct-87 0505 @score.stanford.edu:MUMICK@Sushi.Stanford.EDU CSD Reception
C01128 00187 ∂01-Oct-87 0545 @score.stanford.edu:ball@navajo.stanford.edu CSD-CF RATES
C01134 00188 ∂01-Oct-87 1222 EMMA@CSLI.Stanford.EDU CSLI Calendar, Oct. 1, 3:1
C01139 00189 ∂01-Oct-87 1242 TAJNAI@score.stanford.edu Seminar on Combinatorics
C01140 00190 ∂01-Oct-87 1425 @score.stanford.edu:JMC@SAIL.STANFORD.EDU visiting professors
C01142 00191 ∂01-Oct-87 1436 REULING@Score.Stanford.EDU MJH Offices will close early today
C01144 00192 ∂01-Oct-87 1452 @score.stanford.edu:nilsson@Tenaya.Stanford.EDU visiting professors
C01146 00193 ∂01-Oct-87 1559 @score.stanford.edu:LES@SAIL.STANFORD.EDU CS 300 Schedule
C01149 00194 ∂01-Oct-87 1612 HILBERT@CSLI.Stanford.EDU New Symbolic Systems faculty
C01151 00195 ∂01-Oct-87 1723 @score.stanford.edu:JMC@SAIL.STANFORD.EDU re: visiting professors
C01153 00196 ∂02-Oct-87 1158 @score.stanford.edu:JMC@SAIL.STANFORD.EDU visiting professors and industrial lecturers
C01156 00197 ∂02-Oct-87 1553 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Seminars
C01163 00198 ∂03-Oct-87 1519 @Sushi.Stanford.EDU:MAYR@Score.Stanford.EDU parallel computation seminar
C01165 00199 ∂04-Oct-87 1601 @Sushi.Stanford.EDU:DIETZ%sdr.slb.com%RELAY.CS.NET@forsythe.stanford.edu Calculating the volume of a LP-feasible region
C01167 00200 ∂04-Oct-87 1639 @Sushi.Stanford.EDU:ladner%june.cs.washington.edu@forsythe.stanford.edu Conference Announcement for DIAC-88
C01175 00201 ∂05-Oct-87 1049 RICHARDSON@score.stanford.edu Faculty Lunch
C01176 00202 ∂05-Oct-87 1628 @score.stanford.edu:IRVINE@SUMEX-AIM.STANFORD.EDU $500,000 for research
C01178 00203 ∂05-Oct-87 1738 @score.stanford.edu:nilsson@Tenaya.Stanford.EDU $500,000 for research
C01180 00204 ∂06-Oct-87 1312 @Sushi.Stanford.EDU:svante%DNA.LU.Se@forsythe.stanford.edu Call for papers
C01185 00205 ∂07-Oct-87 0753 TOM@score.stanford.edu SCORE
C01187 00206 ∂07-Oct-87 1152 KUDER@CSLI.Stanford.EDU SSP Phone list
C01188 00207 ∂07-Oct-87 1331 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Polymorphism
C01190 00208 ∂07-Oct-87 1417 HILBERT@CSLI.Stanford.EDU Agenda for Faculty Lunch
C01192 00209 ∂07-Oct-87 1428 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu A finite representation of rationals
C01195 00210 ∂07-Oct-87 1457 HILBERT@CSLI.Stanford.EDU Mellon fellowships
C01198 00211 ∂07-Oct-87 2329 SF@CSLI.Stanford.EDU Seminar in Logic and Foundations of Mathematics
C01200 00212 ∂08-Oct-87 0817 TOM@score.stanford.edu SCORE
C01202 00213 ∂08-Oct-87 1324 @score.stanford.edu:LES@SAIL.Stanford.EDU CS 300 in Winter?
C01206 00214 ∂08-Oct-87 1403 EMMA@CSLI.Stanford.EDU CSLIC CAlendar, Oct. 8, 3:2
C01216 00215 ∂08-Oct-87 1537 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu New Address
C01218 00216 ∂08-Oct-87 1559 RICHARDSON@score.stanford.edu Janos Komlos
C01220 00217 ∂08-Oct-87 1647 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: A call for references on finite representation of rationals.
C01223 00218 ∂08-Oct-87 1711 @score.stanford.edu:nilsson@Tenaya.Stanford.EDU NSF S&T Centers
C01226 00219 ∂09-Oct-87 1314 RICHARDSON@score.stanford.edu Janos Komlos
C01228 00220 ∂09-Oct-87 1350 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB talks
C01233 00221 ∂09-Oct-87 1406 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: A finite representation of rationals
C01241 00222 ∂09-Oct-87 1744 @score.stanford.edu:nilsson@Tenaya.Stanford.EDU [CLOUTIER@Sierra.Stanford.EDU: Senate Proposal Regarding NSF Funds]
C01244 00223 ∂09-Oct-87 1800 @score.stanford.edu:lma@Anna.stanford.edu PAVG Speaker Series
C01247 00224 ∂09-Oct-87 1802 RICHARDSON@score.stanford.edu NSF S&T Centers
C01249 00225 ∂10-Oct-87 1256 BSCOTT@score.stanford.edu Unrestricted Accounts
C01251 00226 ∂12-Oct-87 0144 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #72
C01286 00227 ∂12-Oct-87 0755 RICHARDSON@score.stanford.edu CSD Lunch
C01288 00228 ∂12-Oct-87 0855 BARWISE@CSLI.Stanford.EDU Reminder
C01289 00229 ∂12-Oct-87 0902 RICHARDSON@score.stanford.edu CSD Faculty Lunch
C01290 00230 ∂12-Oct-87 1251 @score.stanford.edu:FEIGENBAUM@SUMEX-AIM.STANFORD.EDU Re: CSD Faculty Lunch
C01292 00231 ∂13-Oct-87 0948 BARWISE@CSLI.Stanford.EDU thanks
C01294 00232 ∂13-Oct-87 1121 TOM@score.stanford.edu INTERLEAF Publishing Demo
C01296 00233 ∂13-Oct-87 1500 RICHARDSON@Score.Stanford.EDU Manufacturing
C01297 00234 ∂14-Oct-87 0211 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #73
C01340 00235 ∂14-Oct-87 0816 BARWISE@CSLI.Stanford.EDU please remind your students
C01342 00236 ∂14-Oct-87 0841 BARWISE@CSLI.Stanford.EDU Faculty Development Lab
C01345 00237 ∂14-Oct-87 0926 @CSLI.Stanford.EDU:nilsson@Tenaya.Stanford.EDU Faculty Development Lab
C01348 00238 ∂14-Oct-87 1016 RICHARDSON@Score.Stanford.EDU NSF Proposal
C01350 00239 ∂14-Oct-87 1219 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com PLANLUNCH NEXT MONDAY: Ramin Zabih, Stanford
C01354 00240 ∂14-Oct-87 1847 EMMA@CSLI.Stanford.EDU CSLI Calendar, Oct. 15, 3:3
C01362 00241 ∂15-Oct-87 1039 EMMA@CSLI.Stanford.EDU Correction on Locations
C01363 00242 ∂15-Oct-87 1135 SCHAFFER@Sushi.Stanford.EDU Meeting with David Johnson
C01365 00243 ∂15-Oct-87 1405 Kabowen@logiclab.cis.syr.edu Call for Papers
C01371 00244 ∂15-Oct-87 1643 TAJNAI@Score.Stanford.EDU Call for Student Speakers, and New Faculty Speakers
C01377 00245 ∂15-Oct-87 1727 TAJNAI@Score.Stanford.EDU Apologies to Andrew Goldberg
C01378 00246 ∂15-Oct-87 1733 TAJNAI@Score.Stanford.EDU Computer Forum is Number ONE!!
C01380 00247 ∂16-Oct-87 1103 PAPA@Score.Stanford.EDU Any UC people around today?
C01382 00248 ∂16-Oct-87 1133 SF@CSLI.Stanford.EDU
C01383 00249 ∂16-Oct-87 1514 SLOAN@Score.Stanford.EDU [Rosemary Napier <RFN@SAIL.Stanford.EDU>:]
C01385 00250 ∂16-Oct-87 1528 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talks
C01389 00251 ∂18-Oct-87 0158 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #74
C01415 00252 ∂18-Oct-87 2320 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com REMINDER -- Tomorrow's Planlunch -- Ramin Zabih
C01419 00253 ∂19-Oct-87 1055 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Wanted: Voronoi diagram construction routine.
C01422 00254 ∂19-Oct-87 1305 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Seminar in Applications of Logic to Computer Science
C01425 00255 ∂19-Oct-87 1547 BSCOTT@Score.Stanford.EDU Reminder, Tuesday Lunch
C01426 00256 ∂20-Oct-87 1003 ULLMAN@score.stanford.edu Paper available
C01428 00257 ∂20-Oct-87 1018 ULLMAN@score.stanford.edu Papers received
C01430 00258 ∂20-Oct-87 1636 @RELAY.CS.NET:DUSSUD@jenner.csc.ti.com Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP 20 Oct 87 16:36:09 PDT
C01433 00259 ∂20-Oct-87 2045 REGES@Score.Stanford.EDU TV students
C01438 00260 ∂20-Oct-87 2053 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu electronic NSF reviews
C01441 00261 ∂20-Oct-87 2123 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu The Funding of Theory
C01444 00262 ∂21-Oct-87 0850 RICHARDSON@Score.Stanford.EDU Softerware Licensing
C01445 00263 ∂21-Oct-87 0859 RICHARDSON@Score.Stanford.EDU Student Profiles
C01446 00264 ∂21-Oct-87 0912 RICHARDSON@Score.Stanford.EDU NSF Program Announcement
C01448 00265 ∂21-Oct-87 2043 BARWISE@CSLI.Stanford.EDU 2 things
C01450 00266 ∂22-Oct-87 0839 ROSENKING@A.ISI.EDU Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP 22 Oct 87 08:39:11 PDT
C01452 00267 ∂22-Oct-87 1038 EMMA@CSLI.Stanford.EDU CSLI Calendar, Oct. 22, 3:4
C01458 00268 ∂22-Oct-87 1137 DEWERK@Score.Stanford.EDU Course Notes Policy
C01461 00269 ∂22-Oct-87 1940 @Score.Stanford.EDU:pratt@chehalis.stanford.edu CS300 lecturers take note
C01463 00270 ∂23-Oct-87 1216 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Error-correcting codes
C01466 00271 ∂23-Oct-87 1435 @Score.Stanford.EDU:CORNELIUS@SUMEX-AIM.STANFORD.EDU Your BIG chance!
C01473 00272 ∂24-Oct-87 1803 SF@CSLI.Stanford.EDU logic seminar
C01474 00273 ∂25-Oct-87 0156 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #76
C01499 00274 ∂26-Oct-87 0522 MATHIS@C.ISI.EDU next meeting
C01502 00275 ∂26-Oct-87 0736 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu The death of A.N. Kolmogorov.
C01505 00276 ∂26-Oct-87 0838 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU Oct 27 lunch
C01507 00277 ∂26-Oct-87 1143 GANGOLLI@Sushi.Stanford.EDU
C01515 00278 ∂26-Oct-87 1233 MATHIS@C.ISI.EDU Wednesday afternoon agenda
C01517 00279 ∂26-Oct-87 1450 @Sushi.Stanford.EDU:hochbaum%newton.Berkeley.EDU@BERKELEY.EDU Feder's talk
C01518 00280 ∂26-Oct-87 1552 TAJNAI@Score.Stanford.EDU US West Announcement of Opportunity
C01521 00281 ∂26-Oct-87 1616 @Sushi.Stanford.EDU:dorit@ernie.Berkeley.EDU tomas Feder's talk
C01523 00282 ∂27-Oct-87 0342 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #78
C01572 00283 ∂27-Oct-87 1425 HADDAD@Sushi.Stanford.EDU BATS: Nov. 12 Bay Area Theory Seminar at Berkeley
C01580 00284 ∂27-Oct-87 1438 HADDAD@Sushi.Stanford.EDU BATS: lunches, parking permits, and rides
C01582 00285 ∂27-Oct-87 1559 TAJNAI@Score.Stanford.EDU call for Forum speakers
C01584 00286 ∂28-Oct-87 0227 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #79
C01606 00287 ∂28-Oct-87 1553 TAJNAI@Score.Stanford.EDU Need Commencement Cap
C01607 00288 ∂28-Oct-87 1732 EMMA@CSLI.Stanford.EDU CSLI Calendar, Oct. 29, 3:5
C01616 00289 ∂28-Oct-87 1927 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU funds
C01618 00290 ∂29-Oct-87 1212 X3J13-mailer November X3J13 meeting
C01635 00291 ∂29-Oct-87 1413 @Score.Stanford.EDU:FACIL-mailer@SAIL.Stanford.EDU maybe we need a facilities meeting
C01638 00292 ∂29-Oct-87 1451 @Score.Stanford.EDU:FACIL-mailer@SAIL.Stanford.EDU Re: maybe we need a facilities meeting
C01640 00293 ∂29-Oct-87 1616 REGES@Score.Stanford.EDU summer instructors?
C01642 00294 ∂29-Oct-87 1725 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com Next Week's PLANLUNCH: David Poole
C01646 00295 ∂29-Oct-87 1733 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu reseach initiation grants
C01650 00296 ∂29-Oct-87 2342 LOGMTC-request
C01651 00297 ∂30-Oct-87 0814 TAJNAI@Score.Stanford.EDU Computer Forum Meeting
C01652 00298 ∂30-Oct-87 0905 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu nsf grants
C01657 00299 ∂30-Oct-87 1154 SLOAN@Score.Stanford.EDU Closing of Offices
C01658 00300 ∂30-Oct-87 1539 @Score.Stanford.EDU:FEIGENBAUM@SUMEX-AIM.STANFORD.EDU Duda
C01659 00301 ∂30-Oct-87 1546 HEMENWAY@Score.Stanford.EDU Grey Tuesday Scheduled
C01661 00302 ∂31-Oct-87 0914 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU annual report
C01668 00303 ∂31-Oct-87 1150 @Score.Stanford.EDU:golub@golubsun.cs.umd.edu Dean's report
C01672 00304 ∂01-Nov-87 1117 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU annual report
C01674 00305 ∂01-Nov-87 1727 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com PLANLUNCH REMINDER -- Monday -- David Poole
C01678 00306 ∂01-Nov-87 1748 @Score.Stanford.EDU:FEIGENBAUM@SUMEX-AIM.STANFORD.EDU Annual Report
C01680 00307 ∂02-Nov-87 0856 RICHARDSON@Score.Stanford.EDU CSD Faculty Lunch
C01681 00308 ∂02-Nov-87 1040 HADDAD@Sushi.Stanford.EDU BATS: final call
C01684 00309 ∂02-Nov-87 1409 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talks
C01693 00310 ∂03-Nov-87 1037 TAJNAI@Score.Stanford.EDU AT&T Bell call for Fellowship Nominees
C01695 00311 ∂03-Nov-87 1136 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU AT&T Bell call for Fellowship Nominees
C01697 00312 ∂03-Nov-87 1546 TOM@Score.Stanford.EDU Campus-wide power shut-down
C01699 00313 ∂03-Nov-87 1835 TAJNAI@Score.Stanford.EDU Bell message correction
C01701 00314 ∂04-Nov-87 0641 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu French-Israeli Conference on Combinatorics and Algorithms
C01707 00315 ∂04-Nov-87 1526 @Score.Stanford.EDU:ullman@navajo.stanford.edu Visit of Maria Klawe
C01709 00316 ∂04-Nov-87 2031 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com Special last minute seminar -- thursday -- Jean-Louis Lassez
C01711 00317 ∂04-Nov-87 2047 @CSLI.Stanford.EDU:emma@russell.stanford.edu CSLI Calendar, November 5, 3:6
C01728 00318 ∂04-Nov-87 2153 LOGMTC-request Drusinsky talk next Friday
C01732 00319 ∂05-Nov-87 0757 RICHARDSON@Score.Stanford.EDU NSF
C01733 00320 ∂05-Nov-87 0942 @WARBUCKS.AI.SRI.COM,@malibu:olender@malibu.ai.sri.com SPECIAL LAST MINUTE SEMINAR / TODAY / JEAN-LOUIS LASSEZ.
C01737 00321 ∂05-Nov-87 1000 HEMENWAY@Score.Stanford.EDU [Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>: Grey Tuesday Scheduled]
C01740 00322 ∂05-Nov-87 1455 TAJNAI@Score.Stanford.EDU SUNRISE CLUB MEETS MONDAY, NOV. 16
C01742 00323 ∂05-Nov-87 1551 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com Next MONDAY's Planlunch Seminar -- Anand Rao
C01746 00324 ∂05-Nov-87 1703 TOM@Score.Stanford.EDU MJH Ethernet down-time schedule
C01748 00325 ∂05-Nov-87 1714 TOM@Score.Stanford.EDU SUSHI MOVE
C01750 00326 ∂06-Nov-87 0914 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Algebraic Logic and Universal Algebra in Computer Science
C01753 00327 ∂06-Nov-87 0940 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Seminar in Applications of Logic to Computer Science
C01756 00328 ∂06-Nov-87 1011 STAGER@Score.Stanford.EDU Final Exams
C01759 00329 ∂06-Nov-87 1129 @CSLI.Stanford.EDU:barwise@russell.stanford.edu move to russell
C01761 00330 ∂06-Nov-87 1130 LOGMTC-request logic seminar
C01762 00331 ∂06-Nov-87 1802 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU SUNRISE CLUB MEETS MONDAY, NOV. 16
C01764 00332 ∂07-Nov-87 1125 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talks
C01773 00333 ∂08-Nov-87 2031 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com REMINDER -- Monday PLANLUNCH -- Anand Rao
C01778 00334 ∂09-Nov-87 0205 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #85
C01798 00335 ∂09-Nov-87 0808 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU Tuesday 11/10 lunch
C01800 00336 ∂09-Nov-87 1439 @Score.Stanford.EDU:ME@SAIL.Stanford.EDU SAIL user disk packs (UDPs) to be retired
C01802 00337 ∂09-Nov-87 1719 ALPERT@Score.Stanford.EDU FRAME MAKER publishing demo
C01805 00338 ∂09-Nov-87 2206 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Marist College Colloquium Series 87-88
C01811 00339 ∂10-Nov-87 0115 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for Papers, ACM Computational Geometry Symposium
C01817 00340 ∂10-Nov-87 0816 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu undecidability of system of first order predicates
C01820 00341 ∂10-Nov-87 0904 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU Associate Chairman
C01825 00342 ∂10-Nov-87 0917 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU Wheaton
C01827 00343 ∂10-Nov-87 1504 @Score.Stanford.EDU:RINDFLEISCH@SUMEX-AIM.STANFORD.EDU SPO Advisory Committee
C01829 00344 ∂10-Nov-87 1520 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU re: SPO Advisory Committee
C01832 00345 ∂10-Nov-87 2000 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu NSPACE
C01835 00346 ∂10-Nov-87 2037 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: undecidability of system of first order predicates
C01839 00347 ∂10-Nov-87 2131 LOGMTC-request logic seminar
C01841 00348 ∂11-Nov-87 0938 TAJNAI@Score.Stanford.EDU Please RSVP for Sunrise Club Breakfast
C01842 00349 ∂11-Nov-87 1028 TAJNAI@Score.Stanford.EDU Nils' Newsletter to Alumni and Friends of the Dept.
C01844 00350 ∂11-Nov-87 1648 EMMA@CSLI.Stanford.EDU CSLI Calendar delayed
C01846 00351 ∂11-Nov-87 1713 X3J13-mailer Final reservations
C01852 00352 ∂11-Nov-87 1800 X3J13-mailer Final reservations
C01858 00353 ∂12-Nov-87 2254 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Parsing 2-dimensional structures
C01860 00354 ∂12-Nov-87 1317 emma@russell.stanford.edu CSLI Calendar, November 12, 3:7
C01863 00355 ∂12-Nov-87 1335 X3J13-mailer next meeting
C01866 00356 ∂12-Nov-87 1400 @Score.Stanford.EDU:CLAPP@Sushi.Stanford.EDU lunch for women interested in CS
C01868 00357 ∂12-Nov-87 1455 @Score.Stanford.EDU,@Sushi.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: lunch for women interested in CS
C01870 00358 ∂12-Nov-87 1548 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: Parsing 2-dimensional structures
C01873 00359 ∂12-Nov-87 1700 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Seminar in Applications of Logic to Computer Science
C01876 00360 ∂13-Nov-87 0809 MAZZETTI@SUMEX-AIM.STANFORD.EDU [Bob Engelmore <Engelmore@SUMEX-AIM.STANFORD.EDU>: Re: Letter]
C01879 00361 ∂13-Nov-87 0836 MAZZETTI@SUMEX-AIM.STANFORD.EDU [Bob Engelmore <Engelmore@SUMEX-AIM.STANFORD.EDU>: please circulate to AAAI Council and Officers]
C01883 00362 ∂13-Nov-87 0908 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: Parsing 2-dimensional structures
C01887 00363 ∂13-Nov-87 1203 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: undecidability of system of first order predicates
C01891 00364 ∂14-Nov-87 0353 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #86
C01939 00365 ∂15-Nov-87 1331 TAJNAI@Score.Stanford.EDU AT&T Bell Nominations
C01941 00366 ∂16-Nov-87 0759 RICHARDSON@Score.Stanford.EDU Faculty Lunch
C01942 00367 ∂16-Nov-87 1144 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: undecidability of system of first order predicates
C01944 00368 ∂16-Nov-87 1204 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: undecidability of system of first order predicates
C01947 00369 ∂16-Nov-87 1218 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talks
C01954 00370 ∂16-Nov-87 1546 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu the synthesis of communication protocols
C01958 00371 ∂16-Nov-87 1606 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Sanitary surgeons and safe sex.
C01963 00372 ∂16-Nov-87 1646 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu CMU meeting on metadeduction
C01968 00373 ∂16-Nov-87 1704 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu LICS competition
C01974 00374 ∂17-Nov-87 1103 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU Special Needs
C01976 00375 ∂17-Nov-87 1329 RICHARDSON@Score.Stanford.EDU A National Computing Initiative
C01978 00376 ∂17-Nov-87 1605 BSCOTT@Score.Stanford.EDU Annual Reports
C01980 00377 ∂18-Nov-87 0250 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #87
C02003 00378 ∂18-Nov-87 1041 ALPERT@Score.Stanford.EDU FRAME MAKER publishing demo
C02006 00379 ∂18-Nov-87 1122 barwise@russell.stanford.edu note of interest
C02008 00380 ∂18-Nov-87 1429 barwise@russell.stanford.edu another ssp-type program that might interest you
C02013 00381 ∂18-Nov-87 1527 TAJNAI@Score.Stanford.EDU Small Business Membership - a member
C02015 00382 ∂18-Nov-87 1610 TAJNAI@Score.Stanford.EDU Poster Sessions and Demos at the Forum
C02017 00383 ∂18-Nov-87 1900 LOGMTC-request Seminar in Logic
C02018 00384 ∂19-Nov-87 1030 TAJNAI@Score.Stanford.EDU [Arthur Keller <ARK@SAIL.Stanford.EDU>: Re: Small Business Membership - a member]
C02021 00385 ∂19-Nov-87 1205 emma@russell.stanford.edu CSLI Calendar, November 19, 3:8
C02028 00386 ∂20-Nov-87 1300 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: Sanitary surgeons and safe sex.
C02031 00387 ∂20-Nov-87 1411 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu On the complexity of maintaining partial sums
C02034 00388 ∂20-Nov-87 1446 SARAIYA@SUMEX-AIM.STANFORD.EDU Wed, 11/25, 9am: AIRTRAC design review
C02036 00389 ∂20-Nov-87 1621 STAGER@Score.Stanford.EDU Tau Beta Pi course surveys
C02038 00390 ∂20-Nov-87 1725 SARAIYA@SUMEX-AIM.STANFORD.EDU PhD Orals
C02044 00391 ∂21-Nov-87 0042 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for Papers - International Neural Netowrk Society
C02068 00392 ∂21-Nov-87 0127 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Supercomputing '88 Conference Announcement and Call for Papers
C02077 00393 ∂22-Nov-87 0134 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #89
C02102 00394 ∂23-Nov-87 0112 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #90
C02116 00395 ∂23-Nov-87 0908 RICHARDSON@Score.Stanford.EDU Faculty Lunch
C02118 00396 ∂23-Nov-87 1120 OKUNO@SUMEX-AIM.STANFORD.EDU Dr. Sridharan's report
C02120 00397 ∂23-Nov-87 1430 TOM@Score.Stanford.EDU Locking of computer room(020)
C02122 00398 ∂23-Nov-87 1658 OKUNO@SUMEX-AIM.STANFORD.EDU my absence in December
C02124 00399 ∂24-Nov-87 0149 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #91
C02140 00400 ∂24-Nov-87 0842 TAJNAI@Score.Stanford.EDU NilsNews to Alumni and Friends
C02142 00401 ∂24-Nov-87 1024 GILBERTSON@Score.Stanford.EDU Wednesday at 3
C02144 00402 ∂24-Nov-87 1404 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talks
C02147 00403 ∂24-Nov-87 1603 @SUMEX-AIM.STANFORD.EDU:HAILPERIN@Sushi.Stanford.EDU vineet singhs oral
C02149 00404 ∂25-Nov-87 1157 ullman@navajo.stanford.edu papers received
C02153 00405 ∂25-Nov-87 1201 TOM@Score.Stanford.EDU csd security
C02155 00406 ∂25-Nov-87 1431 morris@navajo.stanford.edu PODS abstract available
C02157 00407 ∂26-Nov-87 0124 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #93
C02171 00408 ∂29-Nov-87 1424 X3J13-mailer subcommittees
C02175 00409 ∂29-Nov-87 1432 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU visiting committee
C02181 00410 ∂30-Nov-87 0927 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU faculty lunch
C02183 00411 ∂30-Nov-87 1159 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talks
C02189 00412 ∂30-Nov-87 1343 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU Gray Tuesday
C02191 00413 ∂30-Nov-87 1618 TAJNAI@Score.Stanford.EDU Nominations for AT&T Fellowship
C02193 00414 ∂30-Nov-87 1717 SLOAN@Score.Stanford.EDU Xerox Machines
C02194 00415 ∂01-Dec-87 0026 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #94
C02202 00416 ∂01-Dec-87 0950 STAGER@Score.Stanford.EDU Portia/Watson/Jessica
C02203 00417 ∂01-Dec-87 1031 RICHARDSON@Score.Stanford.EDU Library Services Check-List for the Near West Campus
C02225 00418 ∂01-Dec-87 1041 @Score.Stanford.EDU:G.GORIN@MACBETH.STANFORD.EDU Re: Portia/Watson/Jessica
C02227 00419 ∂01-Dec-87 1747 @relay.cs.net,@ai.toronto.edu:mendel@db.toronto.edu Jobs in Toronto
C02229 00420 ∂02-Dec-87 0135 LOGMTC-request Wednesday seminar on dynamic types
C02232 00421 ∂02-Dec-87 0721 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Reference wanted for article on distfix tokens
C02236 00422 ∂02-Dec-87 0836 RICHARDSON@Score.Stanford.EDU Faculty Meeting
C02238 00423 ∂02-Dec-87 0842 RICHARDSON@Score.Stanford.EDU Sr. Faculty Meeting
C02239 00424 ∂02-Dec-87 0939 ullman@navajo.stanford.edu PODS papers accepted
C02246 00425 ∂02-Dec-87 1545 X3J13-mailer 11-87 minutes
C02258 00426 ∂02-Dec-87 1652 emma@russell.stanford.edu CSLI Calendar, December 3, 3:9
C02262 00427 ∂02-Dec-87 2154 REGES@Score.Stanford.EDU Reappointment of Roy Jones
C02265 00428 ∂03-Dec-87 1004 @Score.Stanford.EDU:cheriton@pescadero.stanford.edu Re: Reappointment of Roy Jones
C02267 00429 ∂03-Dec-87 1057 @Score.Stanford.EDU:FEIGENBAUM@SUMEX-AIM.Stanford.EDU Re: Reappointment of Roy Jones
C02270 00430 ∂03-Dec-87 1144 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Reappointment of Roy Jones
C02273 00431 ∂03-Dec-87 1311 @Score.Stanford.EDU:tanya@mojave.stanford.edu
C02277 00432 ∂03-Dec-87 1552 REGES@Score.Stanford.EDU Roy Jones
C02279 00433 ∂03-Dec-87 1607 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com Next Monday's PLANLUNCH -- Marcel Schoppers
C02284 00434 ∂04-Dec-87 0934 TAJNAI@Score.Stanford.EDU Unveiling of the new CSD Brochure
C02286 00435 ∂04-Dec-87 1040 @CSLI.Stanford.EDU:barwise@alan.stanford.edu Summer internships
C02288 00436 ∂04-Dec-87 2202 OKUNO@SUMEX-AIM.Stanford.EDU My E-mail address in Japan
C02290 00437 ∂06-Dec-87 1439 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talk
C02294 00438 ∂06-Dec-87 2303 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com REMINDER -- Monday Planlunch -- Marcel Schoppers
C02299 00439 ∂07-Dec-87 0908 GENESERETH@Score.Stanford.EDU Re: Reappointment of Roy Jones
C02300 00440 ∂07-Dec-87 0956 RICHARDSON@Score.Stanford.EDU Lunch
C02301 00441 ∂07-Dec-87 1210 ullman@navajo.stanford.edu paper received
C02303 00442 ∂07-Dec-87 2316 GENESERETH@Score.Stanford.EDU Grey Tuesday
C02305 00443 ∂07-Dec-87 2331 LOGMTC-request 12/10, 1pm, MJH301: Talk on Automated Induction proofs.
C02308 00444 ∂08-Dec-87 0857 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Sequences, Combinatorics, Compression,
C02314 00445 ∂08-Dec-87 1002 STAGER@Score.Stanford.EDU End Quarter Grade sheets
C02316 00446 ∂08-Dec-87 1129 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Proposed rights income policy change
C02322 00447 ∂08-Dec-87 1253 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Complexity of optimal addition chains
C02324 00448 ∂08-Dec-87 1327 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Optimal cost addition chains
C02327 00449 ∂08-Dec-87 1932 LOGMTC-request Wednesday seminar: Dynamic Types
C02330 00450 ∂09-Dec-87 0843 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #95
C02362 00451 ∂09-Dec-87 1102 @Score.Stanford.EDU:CORNELIUS@SUMEX-AIM.Stanford.EDU You are invited - Computer Forum Poster Session
C02367 00452 ∂09-Dec-87 1404 BERGMAN@Score.Stanford.EDU Winter quarter RAships
C02369 00453 con-Dec-87 0839 RICHARDSON@Score.Stanford.EDU Faculty Lunch
C02370 00454 ∂10-Dec-87 0923 emma@russell.stanford.edu CSLI Calendar, December 10, 3:10
C02377 00455 ∂10-Dec-87 1541 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com Next MONDAY's Planlunch -- Vineet Singh
C02382 00456 ∂10-Dec-87 1603 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Searches
C02385 00457 ∂10-Dec-87 1629 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU re: Searches
C02388 00458 ∂10-Dec-87 1920 @Score.Stanford.EDU:coraki!pratt@Sun.COM Searches
C02392 00459 ∂11-Dec-87 0055 @Score.Stanford.EDU:coraki!pratt@Sun.COM Searches
C02396 00460 ∂11-Dec-87 0140 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #96
C02408 00461 ∂11-Dec-87 0911 @Score.Stanford.EDU:dill@amadeus.stanford.edu faculty recruiting
C02410 00462 ∂11-Dec-87 1157 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Searches
C02413 00463 ∂11-Dec-87 1157 REGES@Score.Stanford.EDU graduate level symbolic systems?
C02415 00464 ∂11-Dec-87 1400 ULLMAN@Score.Stanford.EDU symbolic systems considered harmful
C02417 00465 ∂11-Dec-87 1531 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU re: Searches
C02421 00466 ∂11-Dec-87 1555 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Searches
C02423 00467 ∂11-Dec-87 1610 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU re: Searches
C02424 00468 ∂11-Dec-87 1811 SHOHAM@Score.Stanford.EDU ssp
C02428 00469 ∂12-Dec-87 0053 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Satisfiability Problems in Propositional Logic
C02431 00470 ∂12-Dec-87 0101 @Score.Stanford.EDU:coraki!pratt@Sun.COM ssp
C02433 00471 ∂12-Dec-87 1153 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU re: ssp
C02435 00472 ∂13-Dec-87 1059 @Score.Stanford.EDU:cheriton@pescadero.stanford.edu Re: graduate level symbolic systems?
C02438 00473 ∂13-Dec-87 1121 @Score.Stanford.EDU:cheriton@pescadero.stanford.edu Faculty search heuristics
C02440 00474 ∂13-Dec-87 1605 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Jean Rogers
C02442 00475 ∂13-Dec-87 1825 @Score.Stanford.EDU:FEIGENBAUM@SUMEX-AIM.Stanford.EDU Re: symbolic systems considered harmful
C02445 00476 ∂13-Dec-87 2012 @Score.Stanford.EDU:FEIGENBAUM@SUMEX-AIM.Stanford.EDU Re: graduate level symbolic systems?
C02447 00477 ∂13-Dec-87 2259 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com REMINDER -- Monday Planlunch -- Vineet Singh
C02449 00478 ∂14-Dec-87 0144 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #97
C02475 00479 ∂14-Dec-87 0858 RICHARDSON@Score.Stanford.EDU Faculty Meeting
C02478 00480 ∂14-Dec-87 0903 RICHARDSON@Score.Stanford.EDU Tenured Faculty Meeting
C02480 00481 ∂14-Dec-87 1055 X3J13-mailer March meeting
C02492 00482 ∂14-Dec-87 1127 emma@russell.stanford.edu Revised title and abstract for CSLI Seminar
C02495 00483 ∂14-Dec-87 1220 ullman@navajo.stanford.edu "Non-monotonic reasoning vs. logic programming: a new perspective,"
C02497 00484 ∂15-Dec-87 1045 TOM@Score.Stanford.EDU Campus-wide power shut-down
C02499 00485 ∂16-Dec-87 1310 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com Next Monday's PLANLUNCH -- Lincoln Wallen
C02502 00486 ∂16-Dec-87 1755 emma@russell.stanford.edu CSLI Calendar, December 17, 3:11
C02506 00487 ∂16-Dec-87 2237 LOGMTC-request Talk by Matt Kaufmann on Proof checking, Fri 18 3pm
C02508 00488 ∂17-Dec-87 1142 LOGMTC-request CS359 Winter 1988
C02512 00489 ∂17-Dec-87 1624 LOGMTC-request Monday Planlunch at SRI: Lincoln Wallen
C02515 00490 ∂17-Dec-87 1624 LOGMTC-request Matt Kaufmann's talk is in MJH301, Fri 18, 3pm.
C02516 00491 ∂18-Dec-87 0917 @Sushi.Stanford.EDU:PAPA@Score.Stanford.EDU Re: Complexity of optimal addition chains
C02518 00492 ∂18-Dec-87 1146 SLOAN@Score.Stanford.EDU Reminder
C02519 00493 ∂18-Dec-87 1244 @Score.Stanford.EDU:cheriton@pescadero.stanford.edu Lunch Jan. 5th: CSD Boundary Value/Problems
C02521 00494 ∂18-Dec-87 1331 TAJNAI@Score.Stanford.EDU Merry Christmas from the Computer Forum
C02524 00495 ∂18-Dec-87 1503 CBARSALOU@Score.Stanford.EDU Elevator problem
C02526 00496 ∂21-Dec-87 1935 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com Reminder -- Monday Planlunch -- note ROOM CHANGE
C02529 00497 ∂21-Dec-87 1938 @Score.Stanford.EDU:golub@golubsun.cs.umd.edu Kent Curtis
C02531 00498 ∂21-Dec-87 1940 TAJNAI@Score.Stanford.EDU Computer Forum 20th Annual Meeting
C02537 00499 ∂22-Dec-87 1351 TAJNAI@Score.Stanford.EDU [Ted Shortliffe <Shortliffe@SUMEX-AIM.Stanford.EDU>: retreat posters]
C02540 00500 ∂22-Dec-87 1437 GILBERTSON@Score.Stanford.EDU Holiday Schedule
C02542 00501 ∂23-Dec-87 0128 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #98
C02570 00502 ∂23-Dec-87 1028 barwise@alan.stanford.edu Courses for next quarter
C02572 00503 ∂23-Dec-87 1147 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu PARCELLA '88
C02583 00504 ∂23-Dec-87 1548 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Solution to 2-D search problem
C02586 00505 ∂23-Dec-87 1630 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu ACM Publication policy
C02592 00506 ∂23-Dec-87 2035 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu SIGACT News Educational Forum
C02601 00507 ∂23-Dec-87 2041 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: Complexity of optimal addition chains
C02604 00508 ∂24-Dec-87 1130 ullman@navajo.stanford.edu paper received
C02606 00509 ∂25-Dec-87 0120 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #99
C02619 00510 ∂28-Dec-87 1519 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Preliminary Program STOC '88
C02634 00511 ∂30-Dec-87 1443 RICHARDSON@Score.Stanford.EDU General Faculty Meeting
C02637 00512 ∂30-Dec-87 1448 RICHARDSON@Score.Stanford.EDU Tenured Faculty Meeting
C02639 00513 ∂30-Dec-87 1508 TAJNAI@Score.Stanford.EDU Need Information re Kelar Corporation
C02641 00514 ∂31-Dec-87 0122 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #100
C02669 00515 ∂31-Dec-87 1258 AAAI-OFFICE@SUMEX-AIM.Stanford.EDU New Committees and Chairs
C02675 00516 ∂01-Jan-88 0156 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V6 #1
C02721 00517 ∂02-Jan-88 0120 @Score.Stanford.EDU:FEIGENBAUM@SUMEX-AIM.Stanford.EDU On royalties and Royalty (long message)
C02740 00518 ∂02-Jan-88 0953 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu 1987 Summary/1988 Prospectus
C02754 00519 ∂02-Jan-88 1031 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu royalties, etc.
C02758 00520 ∂02-Jan-88 1919 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU supercomputing considered harmful
C02760 00521 ∂03-Jan-88 1030 LOGMTC-request Logic Seminar, Tues. Jan 5
C02764 00522 ∂03-Jan-88 1135 @Score.Stanford.EDU:cheriton@pescadero.stanford.edu.stanford.edu On royalties and Royalty (short response)
C02766 00523 ∂03-Jan-88 1210 @Score.Stanford.EDU:binford@anaconda supercomputing considered harmful
C02767 00524 ∂03-Jan-88 1446 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu On royalties and Royalty (short response)
C02769 00525 ∂04-Jan-88 0026 @Score.Stanford.EDU:cheriton@pescadero.stanford.edu.stanford.edu Re: supercomputing considered harmful
C02774 00526 ∂04-Jan-88 0121 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V6 #2
C02794 00527 ∂04-Jan-88 0156 @Score.Stanford.EDU:coraki!pratt@Sun.COM 1987 Summary/1988 Prospectus
C02796 00528 ∂04-Jan-88 0755 @Score.Stanford.EDU:FEIGENBAUM@SUMEX-AIM.Stanford.EDU supercomputing/politics
C02798 00529 ∂04-Jan-88 1010 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu supercomputing/politics
C02801 00530 ∂04-Jan-88 1017 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Tuesday, Jan. 5
C02804 00531 ∂04-Jan-88 1022 @Score.Stanford.EDU:coraki!pratt@Sun.COM Supercomputing considered harmless and sexy
C02808 00532 ∂04-Jan-88 1034 @Score.Stanford.EDU:coraki!pratt@Sun.COM On royalties and Royalty
C02812 00533 ∂04-Jan-88 1243 @Score.Stanford.EDU:cheriton@pescadero.stanford.edu.stanford.edu Re: Supercomputing considered harmless and sexy
C02815 00534 ∂04-Jan-88 1306 ARK@sail.stanford.edu EDBT 88 Program
C02836 00535 ∂04-Jan-88 1342 @Score.Stanford.EDU:jlh@vsop.stanford.edu Re: supercomputing/politics
C02839 00536 ∂04-Jan-88 1401 RICHARDSON@Score.Stanford.EDU hello
C02840 00537 ∂04-Jan-88 1520 RICHARDSON@Score.Stanford.EDU summer research program
C02842 00538 ∂04-Jan-88 1759 LOGMTC-request Logic seminar, correction
C02844 00539 ∂04-Jan-88 2357 @Score.Stanford.EDU:coraki!pratt@Sun.COM Supercomputing considered harmless and sexy
C02849 00540 ∂05-Jan-88 0158 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V6 #3
C02875 00541 ∂05-Jan-88 1418 FACIL-mailer Facilities Committee meeting
C02878 00542 ∂06-Jan-88 0526 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V6 #4
C02887 00543 ∂06-Jan-88 1750 emma@russell.stanford.edu CSLI Monthly
C02912 00544 ∂07-Jan-88 0149 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V6 #5
C02934 00545 ∂07-Jan-88 0947 @SUMEX-AIM.Stanford.EDU:Acuff@Sumex-AIM.Stanford.EDU Explorer II upgrades
C02936 00546 ∂07-Jan-88 1136 emma@russell.stanford.edu CSLI Calendar, January 7, 3:12
C02941 00547 ∂07-Jan-88 2110 LOGMTC-request Logic seminar
C02944 00548 ∂08-Jan-88 0925 DELAGI@SUMEX-AIM.Stanford.EDU Re: Explorer II upgrades
C02946 00549 ∂08-Jan-88 1326 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talks
C02951 00550 ∂08-Jan-88 1652 emma@russell.stanford.edu CSLI Talk
C02955 00551 ∂09-Jan-88 1822 LOGMTC-request Logic seminar
C02957 00552 ∂10-Jan-88 1057 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Tues Lunch
C02959 00553 ∂10-Jan-88 1839 LOGMTC-request linear logic
C02960 00554 ∂11-Jan-88 1009 LOGMTC-request Reminder: CS359 starts Tuesday January 12, 1988
C02962 00555 ∂11-Jan-88 1030 LOGMTC-request mailing lists
C02963 00556 ∂11-Jan-88 1056 X3J13-mailer mailings
C02965 00557 ∂11-Jan-88 1221 @SUMEX-AIM.Stanford.EDU:Acuff@Sumex-AIM.Stanford.EDU Explorer II upgrades
C02967 00558 ∂11-Jan-88 1249 X3J13-mailer mailings
C02973 00559 ∂11-Jan-88 1311 LOGMTC-request sorry about the confusion
C02975 00560 ∂12-Jan-88 1353 barwise@alan.stanford.edu Summer internships
C02978 00561 ∂13-Jan-88 0902 BSCOTT@Score.Stanford.EDU Faculty and Staff Public Service Participation
C02983 00562 ∂13-Jan-88 1557 LOGMTC-request logic seminar
C02986 00563 ∂13-Jan-88 1602 LOGMTC-request linear logic
C02987 00564 ∂13-Jan-88 1604 FACIL-mailer Ncube Computer Meeting 1/13/87
C02990 00565 ∂13-Jan-88 1635 emma@russell.stanford.edu CSLI Calendar, January 14, 3:13
C02994 00566 ∂13-Jan-88 1723 TAJNAI@Score.Stanford.EDU SUNRISE CLUB MEETS JANUARY 26, 1988
C02997 00567 ∂14-Jan-88 1351 AAAI-OFFICE@SUMEX-AIM.Stanford.EDU [AAAI <AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>: new committee chairs]
C03004 00568 ∂14-Jan-88 1513 @Score.Stanford.EDU:ZM@SAIL.Stanford.EDU Suggestions for visiting faculty
C03005 00569 ∂14-Jan-88 1606 DEWERK@Score.Stanford.EDU CSD Course Notes Policies
C03008 00570 ∂14-Jan-88 2009 HADDAD@Sushi.Stanford.EDU BATS: Bay Area Theory Seminar, Feb 19.
C03010 00571 ∂15-Jan-88 0751 @Score.Stanford.EDU:CORNELIUS@SUMEX-AIM.Stanford.EDU Your last chance!
C03014 00572 ∂15-Jan-88 1105 FACIL-mailer Home for Ncube
C03016 00573 ∂15-Jan-88 1241 barwise@alan.stanford.edu keeping ssp students posted
C03017 00574 ∂15-Jan-88 1244 barwise@alan.stanford.edu keeping us posted
C03019 00575 ∂17-Jan-88 1345 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talks
C03023 00576 ∂17-Jan-88 2235 ARK@sail.stanford.edu EDBT88 Conference Program
C03044 00577 ∂18-Jan-88 1116 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu [nilsson: Tuesday Lunch]
C03046 00578 ∂18-Jan-88 1626 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Minilabs
C03054 00579 ∂18-Jan-88 1636 GENESERETH@Score.Stanford.EDU Re: Minilabs
C03057 00580 ∂18-Jan-88 2100 REGES@Score.Stanford.EDU switching to Polya
C03062 00581 ∂19-Jan-88 0117 FACIL-mailer more on POLYA
C03065 00582 ∂19-Jan-88 0609 @Score.Stanford.EDU,@score.stanford.edu:cheriton@Pescadero.stanford.edu Re: switching to Polya
C03068 00583 ∂19-Jan-88 0638 @Score.Stanford.EDU:cheriton@Pescadero.stanford.edu Re: Minilabs
C03071 00584 ∂19-Jan-88 0949 GENESERETH@Score.Stanford.EDU Re: switching to Polya
C03073 00585 ∂19-Jan-88 1003 FACIL-mailer RE: more on POLYA
C03075 00586 ∂19-Jan-88 1405 @Score.Stanford.EDU:FEIGENBAUM@SUMEX-AIM.Stanford.EDU Re: switching to Polya
C03077 00587 ∂19-Jan-88 1536 RICHARDSON@Score.Stanford.EDU Opportunity for research funding in computer science
C03079 00588 ∂20-Jan-88 1819 emma@alan.stanford.edu CSLI Calendar, January 21, 3:14
C03087 00589 ∂20-Jan-88 1942 FACIL-mailer Minutes of Facilities Committee meeting of 1/20/87
C03092 00590 ∂20-Jan-88 2042 REGES@Score.Stanford.EDU Another POLYA proposal
C03095 00591 ∂20-Jan-88 2330 LOGMTC-request Logic Seminar
C03098 00592 ∂20-Jan-88 2348 @Score.Stanford.EDU:cheriton@Pescadero.stanford.edu Re: Another POLYA proposal
C03101 00593 ∂21-Jan-88 0828 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: Another POLYA proposal
C03105 00594 ∂21-Jan-88 1043 LOGMTC-mailer Logic-of-Programs Seminar
C03107 00595 ∂21-Jan-88 1325 ULLMAN@Score.Stanford.EDU POLYA accounts
C03109 00596 ∂21-Jan-88 1359 TAJNAI@Score.Stanford.EDU SUNRISE CLUB MEETS TUESDAY, JANUARY 26]
C03111 00597 ∂21-Jan-88 1548 FACIL-mailer Re: Minutes of Facilities Committee meeting of 1/20/87
C03114 00598 ∂21-Jan-88 1623 hilbert@alan.stanford.edu New math requirement
C03119 00599 ∂21-Jan-88 2221 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU industrial lecturers
C03121 00600 ∂22-Jan-88 1134 @Score.Stanford.EDU:binford@anaconda.Stanford.EDU switching to Polya
C03124 00601 ∂22-Jan-88 1656 hilbert@alan.stanford.edu CSLI Internships
C03126 00602 ∂22-Jan-88 1806 TAJNAI@Score.Stanford.EDU Invitation to the 20th Annual Meeting of the Computer Forum
C03130 00603 ∂23-Jan-88 1137 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Polya Policy
C03141 00604 ∂23-Jan-88 1329 LOGMTC-mailer logic lunch
C03142 00605 ∂23-Jan-88 1425 REGES@Score.Stanford.EDU minor addition to POLYA policy
C03145 00606 ∂24-Jan-88 1835 FACIL-mailer Polya
C03150 00607 ∂25-Jan-88 0848 RICHARDSON@Score.Stanford.EDU Awards Summary for Fiscal Year 1986
C03152 00608 ∂25-Jan-88 0930 @Score.Stanford.EDU:ball@navajo.stanford.edu Any interest in the B & H Film Recoder
C03156 00609 ∂25-Jan-88 1016 ULLMAN@score.stanford.edu [<KERSCH%GMUVAX.BITNET@forsythe.stanford.edu>: Advance Program: Expert Database Systems Conference]
C03198 00610 ∂25-Jan-88 1039 @Score.Stanford.EDU:hayes.pa@Xerox.COM Re: minor addition to POLYA policy
C03200 00611 ∂25-Jan-88 1047 @Score.Stanford.EDU:hayes.pa@Xerox.COM Re: minor addition to POLYA policy
C03203 00612 ∂25-Jan-88 1317 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talks
C03207 00613 ∂25-Jan-88 1358 Zaenen.pa@Xerox.COM a little lexical celebration
C03209 00614 ∂25-Jan-88 1426 RICHARDSON@Score.Stanford.EDU faculty lunch
C03210 00615 ∂25-Jan-88 1442 STAGER@Score.Stanford.EDU Fall Quarter Tau Beta Pi
C03211 00616 ∂25-Jan-88 1536 SHEL@ibm.com help
C03212 00617 ∂26-Jan-88 1107 X3J13-mailer voting
C03217 00618 ∂26-Jan-88 1143 FACIL-mailer Polya trade-in
C03220 00619 ∂26-Jan-88 1548 FACIL-mailer [John Sack <GQ.VVN@forsythe.stanford.edu>: The "whois" database]
C03231 00620 ∂26-Jan-88 1554 @Score.Stanford.EDU:VAVASIS@Sushi.Stanford.EDU students & polya
C03235 00621 ∂26-Jan-88 1641 @Score.Stanford.EDU:dill@amadeus.stanford.edu polya
C03237 00622 ∂26-Jan-88 2153 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Polya and Sushi
C03243 00623 ∂27-Jan-88 0915 ULLMAN@Score.Stanford.EDU Polya charges
C03245 00624 ∂27-Jan-88 0926 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: Polya charges
C03248 00625 ∂27-Jan-88 1033 GOLDBERG@Score.Stanford.EDU POLYA
C03250 00626 ∂27-Jan-88 1048 @Score.Stanford.EDU:kolk@polya
C03262 00627 ∂27-Jan-88 1115 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: POLYA
C03264 00628 ∂27-Jan-88 1427 REGES@Score.Stanford.EDU NExpert Object
C03266 00629 ∂27-Jan-88 1647 @Score.Stanford.EDU:pratt@chehalis Re: NExpert Object
C03268 00630 ∂27-Jan-88 1748 emma@alan.stanford.edu CSLI Calendar, January 28, 3:15
C03278 00631 ∂27-Jan-88 2226 LOGMTC-mailer Logic seminar
C03281 00632 ∂28-Jan-88 1028 @Score.Stanford.EDU:cheriton@Pescadero.stanford.edu Re: Any interest in the B & H Film Recoder
C03283 00633 ∂28-Jan-88 1108 FACIL-mailer Re: Polya trade-in
C03285 00634 ∂28-Jan-88 1202 @Score.Stanford.EDU:coraki!pratt@Sun.COM Any interest in the B & H Film Recoder
C03287 00635 ∂28-Jan-88 1418 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com Planlunch NEXT WEDNESDAY -- Yishai Feldman
C03291 00636 ∂28-Jan-88 1659 hilbert@alan.stanford.edu Internships lunch
C03293 00637 ∂28-Jan-88 1825 ames!pyramid!tub!coma!mihalis@ucbvax.berkeley.edu PODS88 Program
C03315 00638 ∂29-Jan-88 1237 RICE@SUMEX-AIM.Stanford.EDU A big thankyou...
C03316 00639 ∂31-Jan-88 1426 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talk
C03319 00640 ∂01-Feb-88 1002 RICHARDSON@Score.Stanford.EDU Faculty Lunch
C03320 00641 ∂01-Feb-88 1511 X3J13-mailer Don't forget mailings
C03322 00642 ∂02-Feb-88 0944 @Score.Stanford.EDU:coraki!pratt@Sun.COM Document standard
C03325 00643 ∂02-Feb-88 1552 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com REMINDER -- Wednesday PLANLUNCH
C03329 00644 ∂02-Feb-88 1746 TAJNAI@Score.Stanford.EDU Statistics on Foreign Students
C03331 00645 ∂02-Feb-88 1907 @Score.Stanford.EDU:LES@SAIL.Stanford.EDU re: Document standard
C03333 00646 ∂02-Feb-88 1928 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: Document standard
C03335 00647 ∂03-Feb-88 0824 @Score.Stanford.EDU:coraki!pratt@Sun.COM maintenance
C03337 00648 ∂03-Feb-88 0919 TAJNAI@Score.Stanford.EDU Re: maintenance
C03340 00649 ∂03-Feb-88 0939 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: maintenance
C03342 00650 ∂03-Feb-88 1045 ullman@navajo.stanford.edu paper received
C03344 00651 ∂03-Feb-88 1159 @Score.Stanford.EDU:LES@SAIL.Stanford.EDU re: maintenance
C03345 00652 ∂03-Feb-88 1251 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com Next MONDAY's PLANLUNCH -- Reid Simmons
C03350 00653 ∂03-Feb-88 1342 hilbert@alan.stanford.edu Internships lunch
C03352 00654 ∂03-Feb-88 1520 FACIL-mailer Polya trade-in
C03354 00655 ∂03-Feb-88 1619 FACIL-mailer re: Polya trade-in
C03356 00656 ∂03-Feb-88 1722 TAJNAI@Score.Stanford.EDU Alan Kay
C03358 00657 ∂03-Feb-88 1723 FACIL-mailer Re: [John Sack <GQ.VVN@forsythe.stanford.edu>: The "whois" database]
C03361 00658 ∂03-Feb-88 1756 emma@alan.stanford.edu CSLI Calendar, February 4, 3:16
C03368 00659 ∂04-Feb-88 0815 HEMENWAY@Score.Stanford.EDU Meeting Reminder
C03369 00660 ∂04-Feb-88 0836 LOGMTC-mailer various talks
C03377 00661 ∂04-Feb-88 0925 LOGMTC-mailer Logic Seminar
C03380 00662 ∂04-Feb-88 0949 FACIL-mailer Polya/Sushi
C03382 00663 ∂04-Feb-88 1133 FACIL-mailer Re: Polya/Sushi
C03385 00664 ∂04-Feb-88 1136 STAGER@Score.Stanford.EDU Final Exams
C03388 00665 ∂04-Feb-88 1526 TAJNAI@Score.Stanford.EDU Reminder to RSVP
C03389 00666 ∂04-Feb-88 1630 AAAI-OFFICE@SUMEX-AIM.Stanford.EDU Election Results
C03392 00667 ∂05-Feb-88 1001 HEMENWAY@Score.Stanford.EDU Batch 1 Ready after 4:00
C03395 00668 ∂05-Feb-88 1017 LOGMTC-mailer Logic lunch
C03396 00669 ∂05-Feb-88 1033 @Score.Stanford.EDU:ag@pepper.stanford.edu Re: Batch 1 Ready after 4:00
C03398 00670 ∂05-Feb-88 1035 HEMENWAY@Score.Stanford.EDU Re: Batch 1 Ready after 4:00
C03400 00671 ∂05-Feb-88 1038 GENESERETH@Score.Stanford.EDU Re: Batch 1 Ready after 4:00
C03402 00672 ∂05-Feb-88 1518 HADDAD@Sushi.Stanford.EDU BATS Friday, Feb 19 at Xerox
C03415 00673 ∂07-Feb-88 1926 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com REMINDER -- Monday Planlunch -- Reid Simmons
C03420 00674 ∂08-Feb-88 0825 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu robots for lunch!
C03422 00675 ∂08-Feb-88 0837 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Forsythe Lectures
C03424 00676 ∂08-Feb-88 1216 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Visiting Committee Report
C03433 00677 ∂08-Feb-88 1603 hilbert@alan.stanford.edu Reminder about Internships lunch
C03435 00678 ∂08-Feb-88 1622 hilbert@alan.stanford.edu Cog. Sci. grad programs at other institutions
C03437 00679 ∂08-Feb-88 1656 TAJNAI@Score.Stanford.EDU Nils Nilsson's announcement
C03440 00680 ∂09-Feb-88 0926 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Would someone send me this paper?
C03442 00681 ∂09-Feb-88 0930 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu PODC88 Submissions - Maybe Erroneously Returned
C03445 00682 ∂09-Feb-88 0936 AAAI-OFFICE@SUMEX-AIM.Stanford.EDU Executive Council Meeting
C03447 00683 ∂09-Feb-88 0941 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Change of address
C03449 00684 ∂09-Feb-88 0944 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu COLOG-88: Preliminary Announcement
C03453 00685 ∂09-Feb-88 0953 GANGOLLI@Sushi.Stanford.EDU NO AFLB THIS WEEK
C03454 00686 ∂09-Feb-88 1002 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Complexity Day at Northeastern University
C03459 00687 ∂09-Feb-88 1011 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu WG88
C03466 00688 ∂09-Feb-88 1017 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Workshop on Specification and Verfication of Concurrent Systems
C03472 00689 ∂09-Feb-88 1021 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu PODC88 Call For Papers
C03480 00690 ∂09-Feb-88 1026 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for papers
C03487 00691 ∂09-Feb-88 1034 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu PODS88 Program
C03509 00692 ∂10-Feb-88 1447 ullman@navajo.stanford.edu paper received
C03512 00693 ∂10-Feb-88 1706 TAJNAI@Score.Stanford.EDU You are Invited to the Forum Reception Thursday, 4:30-6, FAculty Club
C03514 00694 ∂10-Feb-88 1721 CBARSALOU@Score.Stanford.EDU
C03516 00695 ∂10-Feb-88 1756 @Score.Stanford.EDU:MYERS@Sushi.Stanford.EDU Winter Quarter Potluck
C03518 00696 ∂10-Feb-88 2009 emma@alan.stanford.edu CSLI Calendar, February 11, 3:17
C03530 00697 ∂11-Feb-88 0900 LOGMTC-mailer two events
C03532 00698 ∂11-Feb-88 1047 HEMENWAY@Score.Stanford.EDU A Few Important Things
C03535 00699 ∂11-Feb-88 1137 DEWERK@Score.Stanford.EDU Course Notes
C03537 00700 ∂11-Feb-88 1339 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu "what is a good hash function for this problem"
C03540 00701 ∂11-Feb-88 1630 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu MULIPLE ERROR ON PODC88 MESSAGES
C03542 00702 ∂11-Feb-88 1644 @Score.Stanford.EDU:rav@Pescadero.stanford.edu FORUM reception
C03544 00703 ∂11-Feb-88 2035 REGES@Score.Stanford.EDU leaving Stanford
C03547 00704 ∂11-Feb-88 2105 LOGMTC-mailer Logic Seminar
C03549 00705 ∂11-Feb-88 2312 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Princeton Forum on Algorithms and Complexity
C03557 00706 ∂12-Feb-88 0030 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talks
C03562 00707 ∂12-Feb-88 0216 @Score.Stanford.EDU:DURAN@Sushi.Stanford.EDU Students and Polya
C03578 00708 ∂12-Feb-88 0832 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu INNS 88 UPDATE AND CALL FOR PAPERS
C03613 00709 ∂12-Feb-88 0906 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu leaving Stanford
C03616 00710 ∂12-Feb-88 0921 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Students and Polya
C03618 00711 ∂12-Feb-88 0958 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Computing and Polya
C03621 00712 ∂12-Feb-88 1022 @Score.Stanford.EDU:jwilson@polya Students and Polya
C03624 00713 ∂12-Feb-88 1147 BERGMAN@Score.Stanford.EDU Spring quarter RAships
C03626 00714 ∂12-Feb-88 1227 @Score.Stanford.EDU:TEICH@Sushi.Stanford.EDU Re: Students and Polya
C03628 00715 ∂12-Feb-88 1533 @Score.Stanford.EDU:CREW@Sushi.Stanford.EDU Re: Students and Polya
C03630 00716 ∂12-Feb-88 1720 @Score.Stanford.EDU:jlh@vsop.stanford.edu visit of Faculty candidates
C03633 ENDMK
C⊗;
∂20-Jul-87 1710 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com WEDNESDAY PLANLUNCH -- THIS WEDNESDAY -- Toyoaki Nishida
Received: from WARBUCKS.AI.SRI.COM by SAIL.STANFORD.EDU with TCP; 20 Jul 87 17:10:40 PDT
Received: from venice by WARBUCKS.AI.SRI.COM via SMTP with TCP; Mon,
20 Jul 87 17:05:55-PDT
Received: by venice (3.2/4.16) id AA19947 for
planlunch@warbucks.ai.sri.com; Mon, 20 Jul 87 17:07:21 PDT
Date: Mon, 20 Jul 87 17:07:21 PDT
From: Amy Lansky <lansky@venice.ai.sri.com>
Message-Id: <8707210007.AA19947@venice>
To: planlunch@warbucks.ai.sri.com
Subject: WEDNESDAY PLANLUNCH -- THIS WEDNESDAY -- Toyoaki Nishida
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
FIGURING OUT MOST PLAUSIBLE INTERPRETATION FROM CONSTRAINTS
Toyoaki Nishida
Kyoto University
Toyoaki.Nishida%doshita.kuis.kyoto-u.junet%utokyo-relay.csnet@RELAY.CS.NET
11:00 AM, WEDNESDAY, July 22
SRI International, Building E, Room EJ228
∂21-Jul-87 1253 edsel!bhopal!jonl@labrea.stanford.edu LOOP "Blurb & Crib Sheet"
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Jul 87 21:32:15 PDT
Received: by labrea.stanford.edu; Mon, 20 Jul 87 21:27:58 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA05329; Fri, 17 Jul 87 12:32:41 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA00290; Fri, 17 Jul 87 12:36:46 PDT
Date: Fri, 17 Jul 87 12:36:46 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8707171936.AA00290@bhopal.edsel.uucp>
To: labrea!x3j13%SAIL@labrea.stanford.edu
Subject: LOOP "Blurb & Crib Sheet"
Comment: Remailed at SAIL.STANFORD.EDU after delay caused by mailing list error.
LOOP Iteration Macro BLURB
WHAT IT IS:
LOOP syntax is an extension of the Common Lisp LOOP macro (CLtL, p 121), and
is expanded into other simpler Common Lisp primitives; the LOOP facility may
thus be thought of as a parser (or as a compiler) into more primitve lisp.
Parsing is controlled by Loop token words, which are simply symbols like FOR,
UNTIL, MAXIMIZE etc. A list of the more common Loop token words, along with
their syntax of usage, appears in the attached "CRIB SHEET".
HOW TO PARSE (and "READ") LOOP CLAUSES:
Each syntactic part of a LOOP construct is called a "clause," whose scope
is determined by the top-level parsing of the Loop token words. This
example contains a few of the possible clauses, to be explained below:
(LOOP FOR i FROM 1 TO (compute-top-value) ;first clause
WHILE (not (unacceptablep i)) ;second clause
COLLECT (square i) ;third clause
DO (format t "Working on ~D now" i) ;fourth clause
WHEN (evenp i) ;fifth clause
DO (format t "~D is a non-odd number" i)
FINALLY (format t "About to exit!!")) ;sixth clause
FROM and TO are also Loop token words, but they are auxiliaries to the FOR
clause. Just how many forms comprise a clause depends on the Loop token
word that starts the clause and on the auxiliary tokens connected with it.
ORDER OF EXECUTION:
Except as noted below, clauses are executed in the same order as they appear
in source code, just as if they were inside one big PROGN. This is repeated
over and over until some clause causes termination, or until a Lisp RETURN,
GO, or THROW, is executed. The exceptions to "linear order" are:
-- Variable initializations are all done first, regardless of where in
the loop body the clause that established the variable is located.
-- The INITIALLY clause (if any) is executed once, before cycling
through the rest of the code.
-- The FINALLY clause (if any) is executed once, before exiting, except
when the code is exited by a Common Lisp GO, RETURN, or THROW.
(Another exception is THEREIS/ALWAYS/NEVER clauses; see the Loop
reference manual for details).
-- Clauses labeled "Iteration Control" (such as FOR i from 1 to 10 ...)
implicitly cause:
+ a variable initialization to be done "initially";
+ a variable "stepping" to be done, generally, between
each execution of the PROGN-like loop body; and
+ a termination test to be performed, generally, just
before the execution of the loop body.
KINDS OF LOOP CLAUSES:
Clauses turn into Lisp code that falls into one of several categories:
** Variable initializating and possibly incrementing:
-- FOR (and its synonym AS) establish a variable to be initialized.
These are called "Iteration control" clauses, and are further
distinguished by auxiliary tokens such as IN, BY, FROM, etc.
FOR/AS clauses also produce code to re-initialize the variable
each time around the loop. When used with the auxiliary "=",
the same form used for the first initialization code is used for
the re-initialization code. With any auxiliary like FROM, UPTO,
DOWN, etc. the re-initialization is a numerical increment by INCF
(or by DECF) defaulting to 1, but changeable by auxiliary BY.
-- Multiple FOR/AS clauses may be combined either serially or
sequentially with the token AND (This is an advanced topic --
see the Loop reference manual for details.)
-- WITH is basically equivalent to a single LET clause. Multiple
WITH clauses may be combined either serially or sequentially
using the token AND (see the Loop reference manual for details).
** Value accumulation
-- COLLECT takes just one form in its clause, and tacks the value
of that form onto the end of a list of values to be returned
when the loop finishes.
-- APPEND is like collect except the value is considered to be
a list of zero or more individual values to be tacked on.
-- SUM takes just one form in its clause, which must evaluate to a
number; the sum of the numbers is returned when the loop finishes.
-- COUNT takes just one form in its clause, and counts the times it
evaluates to non-nil; the count is returned when the loop finishes.
-- MINIMIZE takes just one form in its clause, and keeps track of the
minimum value attained by evaluating that form; this minimum value
is returned when the loop finishes.
-- MAXIMIZE (similar to MINIMIZE).
-- THEREIS, explained below, will cause the non-null value of its
termination predicate to be returned; **however** termination
may occur due to some other clause, in which case the THEREIS
clause does not affect anything.
-- <...>ING -- most of these token words can also be suffixed with ING
** Termination conditions
-- (LOOP-FINISH) is a macro (rather than a token word or clause)
essentially equivalent to a RETURN out of the loop. However,
an accumulated value (if any) is returned instead of nil, and a
FINALLY clause (if any) is also executed.
-- FOR/AS clauses contribute a termination test determined by
the nature of the "Iteration control"
-- WHILE takes just one form, <condition>, in its clause and is
equivalent to the code: (if (not <condition>) (loop-finish)).
-- UNTIL is an inverse of WHILE: (if <condition> (loop-finish)).
-- THEREIS, like UNTIL, takes just one form in its clause, and causes
termination whenever that form evaluates to non-nil; unlike UNTIL,
it does not call (LOOP-FINISH), but directly returns the non-null
value from its form.
-- ALWAYS is like WHILE, but directly returns NIL whenever its
<condition> form evaluates to "false" (i.e., nil).
-- NEVER is like WHILE, but directly returns NIL whenever its
<condition> form evaluates to "true" (i.e., non-nil).
** Unconditional execution
-- DO clauses include all forms up to the next Loop token word;
they are all executed each time around the loop body.
-- DOING is a synonym for DO.
** Conditionals
-- IF clauses take one form as a predicate, and a subsequent value
accumulation clause (or DO or nested conditional clause) that
is executed during the loop body phase if the predicate is true.
-- WHEN is a synonym for IF.
-- UNLESS is like WHEN, but complements the predicate.
-- an ELSE clause is an optional component of an IF, WHEN, or UNLESS
clause, and is executed when the predicate is false.
KINDS OF ITERATION CONTROLS
** Iterating over integers, including or not including the endpoint:
(loop for i from 1 to 10 do ...) ;range includes 1, 2, ... and 10
(loop for i from 1 below 10 do ...) ; includes 1, 2, ... but not 10
(loop for i upto 10 do ...) ; includes 0 (default) ... and 10
(loop for i from 10 above 1 do ...) ; includes 10, 9 , 8 ... but not 1
(loop for i below 10 do ...) ; includes 0 (default) ... not 10
** Iterating over lists
(loop for item in baz-list do ...) ;somewhat like dolist
(loop for tail on baz-list do ...) ;somewhat like maplist
(loop for item in baz-list by #'cddr do ...) ;skips alternate items
** Iterating over Common Lisp sequences (access via ELT):
(loop for a being the elements of <some-sequence> ...)
** Repeated setting of variable to same evaluation:
(loop for x = (read-char) until (funny-char-p x) do (process-char x))
** Value on first time computed differently than on subsequent iterations:
(loop for x = #\( then (read-char) ...)
;; First time, x is set to #\(; subsequent times it calls read-char.
DESTRUCTURING and TYPE DECLARATIONS
A list may be used whereever a variable is called for, and the value for
that "variable" will be "destructured" (see CLtL, p146). Variables may
be followed by optional type specifiers, which are limited to FIXNUM
INTEGER, NUMBER, NOTYPE, T and the floating-point types. These are
considered advanced topics; see the Loop reference manual for details.
!
LOOP Iteration Macro CRIB SHEET
Below is an abbreviated list of the more commonly used LOOP syntax tokens
(sometimes called "Loop Keywords"); a BNF description of the legal format
is given, along with an example for each one.
Iteration Control
------------------------------------------------------------------------------
FOR <var> [{FROM | DOWNFROM | UPFROM} <expr1>]
[{TO | DOWNTO | UPTO | BELOW | ABOVE} <expr2]
[BY <expr3>]
(loop for i integer from 0 to 10 by 2
do (format t "~A" i)) ==> 0 2 4 6 8 10
(loop for i downfrom 6 above 0
do (format t "~A" i)) ==> 6 5 4 3 2 1
FOR <var> IN <expr1> [BY <step-function>]
(loop for i in '(1 2 3) sum i) ==> 6
FOR <var> ON <expr1> [BY <step-function>]
(loop for (i) on '(1 2 3) sum i) ==> 6
FOR <var> FIRST <expr1> THEN <expr2>
FOR <var> = <expr1> [THEN <expr2>]
(loop for i first 2 then (* i i)
until (> i 500)
collect i) ==> (2 4 16 256)
(loop for i = (read-char)
until (eql i #\newline)
collect i) ==> (#\a #\b ...)
FOR <var> BEING EACH ELEMENT OF <sequence>
FOR <var> BEING THE ELEMENTS OF <sequence>
(loop for dollars being each element of #(2 9 4 6)
sum dollars) ==> 21
(loop for char being the elements of (the simple-string "abcd")
collect char) ==> (#\a #\b #\c #\d)
AS is a synonym for FOR
REPEAT
(loop repeat 3 (print "What I say three times it true"))
==> "What I say three times it true"
"What I say three times it true"
"What I say three times it true"
End-Test Control
------------------------------------------------------------------------------
THEREIS <predicate>
(loop for i upfrom 0 thereis (and (> i 10) i)) ==> 11
ALWAYS and NEVER are similar to THEREIS:
(loop for i from 0 to 10 by 3 always (< i 10)) ==> T
(loop for i from 0 to 9 by 3 always (< i 9)) ==> NIL
(loop for i from 0 to 10 never (> i 11)) ==> T
LOOP-FINISH
(loop for i from 1 to 10
do (format t "~A " i)
(loop-finish)) ==> 1
WHILE <predicate>
UNTIL <predicate>
(loop while (hungry-p) do (eat))
(loop until (not (hungry-p)) do (eat))
Value Accumulation
------------------------------------------------------------------------------
COLLECT <item> [INTO <var>]
(loop for i from 1 to 5 collect i) ==> (1 2 3 4 5)
APPEND <list> [INTO <var>]
(loop for i in '((a) (b) ((c) d)) append i) ==> (A B (C) D)
NCONC is similar to append, but uses NCONC function rather than APPEND.
SUM <number> [INTO <var>]
(loop for i in '(1 2 3 4 5)
sum i into lots
finally (return (list lots lots))) ==> (15 15)
COUNT <form> [INTO <var>]
(loop for i in '(a 2 nil c t "x") count i) ==> 5
;; Remember -- nil is not counted
MAXIMIZE <expr> [INTO <var>]
MINIMIZE <expr> [INTO <var>]
(loop for i in '(2 1 5 3 4)
maximize i into moby
finally (cogitate-upon moby)) ==> NIL
;; No automatic return value, bug 'cogitate-upon'
;; is called with value 5 in the finally clause.
Binding Variables
------------------------------------------------------------------------------
WITH <var> [= <initial-value>]
(loop with x = 10
for i from 1 to 3
do (format t "~A " x)) ==> 10 10 10
Conditional Execution
------------------------------------------------------------------------------
<c-clause> ::=
{ DO <form>+ | {COLLECT <item> | APPEND <list> | SUM <number> | etc.} }
IF <predicate> <c-clause> [ELSE <c-clause>]
WHEN <predicate> <c-clause> [ELSE <c-clause>]
(loop for i from 1 to 10
if (< i 5)
do (format t "~A " i)
else
do (format t "*")) ==> 1 2 3 4 *****
UNLESS <predicate> <c-clause> [ELSE <c-clause>]
(loop for i from 1 to 10 unless (< i 5) count i) ==> 6
Unconditional Execution
------------------------------------------------------------------------------
DO <form>+
(loop for i from 16 to 18
do (format t "~D " i)
(format t "~X " i)) ==> 16 10 17 11 18 12
Initial and Final Evaluation
------------------------------------------------------------------------------
INITIALLY <form>
(loop initially (format t "++ ")
for i from 1 to 5
do (format t "~A " i)) ==> ++ 1 2 3 4 5
FINALLY <form>
(loop finally (format t "++")
for i from 1 to 5
do (format t "~A " i)) ==> 1 2 3 4 5 ++
!
LOOP EXAMPLES
Since the LOOP facility is implemented as an ordinary Common Lisp macro,
it is often instructive to call MACROEXPAND-1 on a LOOP expression to
see how it gets translated into "vanilla" code. In the example below,
the goal of the loop is to find the tail of '*temporary-code*' just before
the cell that contains a suitable code-vector; this cell will subsequently
be "spliced" out of the *temporary-code* list.
(macroexpand-1 '(loop initially (setq temp-cell *temporary-code*)
while (not (null (rest temp-cell)))
thereis (<=& len (code-length (second temp-cell)))
do (pop temp-cell)))
==>
(let ((#:it1 nil))
(block nil
(tagbody
(setq temp-cell *temporary-code*)
loop::begin-loop
(unless (not (null (rest temp-cell)))
(loop-finish))
(when (setq #:it1 (<=& len (code-length (second temp-cell))))
(return #:it1))
(pop temp-cell)
(go loop::begin-loop)
loop::end-loop)))
Here is another realistic, complex example taken from one version of the
Lucid debugging module. Notice how the essential control parts of the loop
structure are highlighted by being at "top level":
-- there are few (if any) hidden exits from the loop.
-- Numerical "stepping" is invoked by a very succinct, stylized syntax
reminiscent of mathematical notation, rather than the cumbersome,
and distributed, code parts for Common Lisp DO.
-- "stepping" that doesn't fit into the provided formats can be
modeled by a three-line sequence of WITH/DO/WHILE clauses.
(loop for i upfrom (- frames-to-skip) ;'i' < 0 while skipping; and
below (or limit infinity) ; maybe there's no limit?
with fp = first-fp ;'fp' will chain through
do (setq fp (next-valid-fp ; the sequence of valid
fp ; stack frame pointers.
stack-bottom
report-problems))
while fp ;End of stack? if so, exit now
when (and table-length ;Make sure frame fits
(>= i table-length))
do (format *error-output* ;foo
"Error collecting stack frames")
(loop-finish)
when (and (>= i 0) ;Not skipping
frame-environment) ;Want frame recorded?
do (setf (stack-frame-fp i frame-environment)
fp)
finally (return ;Return # of non-skipped frames
;;I points to the first unused slot in all exit cases,
;;so I is the number of frames stored (or counted)
(max i 0)) ;But never negative
)
∂21-Jul-87 1253 edsel!bhopal!jonl@labrea.stanford.edu "Iteration" activity
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Jul 87 21:32:01 PDT
Received: by labrea.stanford.edu; Mon, 20 Jul 87 21:27:53 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA05324; Fri, 17 Jul 87 12:30:44 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA00277; Fri, 17 Jul 87 12:34:45 PDT
Date: Fri, 17 Jul 87 12:34:45 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8707171934.AA00277@bhopal.edsel.uucp>
To: labrea!x3j13%SAIL@labrea.stanford.edu
Subject: "Iteration" activity
Comment: Remailed at SAIL.STANFORD.EDU after delay caused by mailing list error.
The large LOOP document I informally passed out at the Boston meeting
is a "reference" manual, and as such was intended for scrutiny by those
who are already are MIT-style LOOP lovers. Unfortunately, it seems to
be too much to digest for the novice, so I've prepared a 1-page "Blurb"
and a 1-page "Crib Sheet" to assist the kind of person who doesn't want
to be a LOOP wizard, but may want to have a working knowledge of it
[e.g., to read other people's code, or just to understand this common
but not universal iteration paradigm].
I would like to put this short document formally before the committee
as a readable report on the syntax and semantics of the MIT-style LOOP.
The next message from me to X3J13 will be three pages which are the text
of a "Blurb" (short, working-knowledge overview), a "Crib Sheet" (BNF
syntax with examples for most usages), and a set of two larger examples.
These three pages would be "hardcopied" by printing the "Blurb" in two
columns, 72 lines per column, landscape orientation, on one side of a
sheet, with the "Crib Sheet" similarly printed on the other side. The
"LOOP Examples" page may be viewed as a pop quiz, to see if you can
actually read production-level LOOP code.
Other iteration committee members have indicated they would submit some
additional material for X3J13 consideration, but time constraints seem to
have postponed them [e.g., Chris Perdue wanted to describe an Alphard-
style system, and Pavel Curtis had some ideas on changing or extending
the "collector" syntax of the MIT-style LOOP]. There is also some
question about whether or not to put the LETS reference manual and
code into the X3J13 arena; its size is comparable to that of LOOP, and
as yet we don't have any serious advocates for it on the committee.
-- JonL --
∂21-Jul-87 1908 SCHAFFER@Sushi.Stanford.EDU Next AFLB
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 Jul 87 19:07:56 PDT
Date: Tue 21 Jul 87 19:00:07-PDT
From: Alejandro Schaffer <SCHAFFER@Sushi.Stanford.EDU>
Subject: Next AFLB
To: aflb.all@Sushi.Stanford.EDU
Message-ID: <12320265580.12.SCHAFFER@Sushi.Stanford.EDU>
23-July-1987: Jack Snoeyink (Stanford)
Stabbing Vertical Segments with a Convex Polygon
(joint work with Michael T. Goodrich of The Johns Hopkins Univ.)
A collection of segments S = {s1, s2, ..., sn} in the plane R↑2 is
*stabbed* by a convex polygon P if the boundary of P intersects every
segment in S. Arie Tamir at the Fourth NYU Computational Geometry Day
posed the problem of finding a convex stabbing polygon for S or
determining that none exists. In this talk we restrict S to contain
only vertical segments develop an optimal O(n log n) time and linear
space algorithm.
We distinguish two cases for stabbing polygons, based on a notion of a
`canonical'' stabbing polygon. In one case either the upper or lower
chain of the canonical stabbing polygon is a simply a line segment, in
the other both upper and lower chains are non-trivial. (Somewhat
surprisingly, the former appears more difficult than the latter.) In
each case, we solve the stabbing problem by transforming it to what we
will call a *bipartite stabbing problem*. We show how to solve this
problem in O(n log n) time and O(n) space using the notion of
geometric duality.
We reduce both cases of the convex stabbing problem to this bipartite
stabbing problem in O(n log n) time and O(n) space, where n is the
number of segments in S, thus solving the convex stabbing problem in
these same bounds. Our reduction in both cases is based on a
`point-sweeping' paradigm (or, alternatively, a `chain-unwrapping'
paradigm).
***** Time and place: July 23, 12:30pm in MJ352 (Bldg. 460) *****
-------
∂22-Jul-87 0741 FAHLMAN@C.CS.CMU.EDU Iteration proposals
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Jul 87 07:41:25 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 22 Jul 87 10:36:19-EDT
Date: Wed, 22 Jul 1987 10:36 EDT
Message-ID: <FAHLMAN.12320403233.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: x3j13@SAIL.STANFORD.EDU
Subject: Iteration proposals
I have a few comments on Loop and the other iteration proposals, but I
assume that this is not the proper forum for detailed discussions,
especially of a preliminary nature. Is the iteration subcommittee now
active, with an internal communication channel for this stuff?
-- Scott
∂22-Jul-87 0746 RICHARDSON@Score.Stanford.EDU SOE Directory
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 22 Jul 87 07:46:25 PDT
Date: Wed 22 Jul 87 07:39:41-PDT
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: SOE Directory
To: faculty@Score.Stanford.EDU
Message-ID: <12320403854.9.RICHARDSON@Score.Stanford.EDU>
As follow-up to a message sent to you by Kathy Berg, I'd like to remind
those of you that have not responded of the following:
If we do not hear from you by this Friday (July 24), we will use the research
blurb (which Kathy sent to you) for the SOE directory as it stands.
Thanks,
Anne
-------
∂22-Jul-87 0924 DEWERK@Score.Stanford.EDU [Stuart Reges <REGES@Score.Stanford.EDU>: summer camp]
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 22 Jul 87 09:24:33 PDT
Date: Wed 22 Jul 87 09:18:10-PDT
From: Gerda de Werk <DEWERK@Score.Stanford.EDU>
Subject: [Stuart Reges <REGES@Score.Stanford.EDU>: summer camp]
To: faculty@Score.Stanford.EDU
Message-ID: <12320421781.14.DEWERK@Score.Stanford.EDU>
Many thanks to those who have already responded to this message. If
you haven't had a chance to reply, and are interested in giving a
talk, please let me know as soon as possible.
Thanks,
Gerda
---------------
Mail-From: REGES created at 1-Jul-87 16:08:37
Date: Wed 1 Jul 87 16:08:37-PDT
From: Stuart Reges <REGES@Score.Stanford.EDU>
Subject: summer camp
To: faculty@Score.Stanford.EDU
Office: CS-TAC 22, 723-9798
Message-ID: <12314991477.33.REGES@Score.Stanford.EDU>
A little over a year ago I mentioned the idea of a summer camp for talented
high school students. The camp will become a reality this summer thanks to
help from Jeff Ullman, Roy Jones, and James Wilson. We have invited two groups
of 30 high school students to come for a week (Aug 17-21 and Aug 24-28). If
any of you will be around during that time and would like to give a talk about
your research, please let us know. I am particularly interested in arranging
some early evening talks in the dorm lounge, because I think that more informal
atmosphere would be just right. If you volunteer to give a talk, please CC
your response to Gerda de Werk (DEWERK@SCORE) since she will be coordinating
things during the times I'm on vacation this summer.
-------
-------
∂23-Jul-87 0944 edsel!bhopal!jonl@labrea.stanford.edu Iteration proposals
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 87 09:44:42 PDT
Received: by labrea.stanford.edu; Thu, 23 Jul 87 09:40:32 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA01235; Wed, 22 Jul 87 19:49:39 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA03169; Wed, 22 Jul 87 19:49:57 PDT
Date: Wed, 22 Jul 87 19:49:57 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8707230249.AA03169@bhopal.edsel.uucp>
To: labrea!Fahlman%C.CS.CMU.EDU@labrea.stanford.edu
Cc: labrea!x3j13%sail@labrea.stanford.edu
In-Reply-To: "Scott E. Fahlman"'s message of Wed, 22 Jul 1987 10:36 EDT <FAHLMAN.12320403233.BABYL@C.CS.CMU.EDU>
Subject: Iteration proposals
At the Palo Alto X3J13 meeting in mid-March, Chris Perdue offered to set up a
mail redistribution list for the iteration sub-committee, at Sun. After a
few false starts, I think some mail successfully was forwarded through
"sun!clam!loop-groop"; but about mid-May, several of the committee members
fell into the proverbial black hole of "other committments", and there
haven't been any mailings through that channel since then.
None of the iteration committe members were present at the Boston meeting
except myself (and you weren't there either?); so we didn't even have our
face-to-face meeting, as planned. For the time being, I guess individual
contact is still the only active channel; the addresses, as last I knew
them, were:
edsel!jonl@labrea.stanford.edu (Jon L White)
DLW@SCRC.Symbolics.COM (Dan Weinreb)
cperdue@sun.COM (Chris Perdue)
Pavel.pa@Xerox.COM (Pavel Curtis)
GSB@mc.lcs.mit.edu (Glenn Burke)
-- JonL --
∂23-Jul-87 1040 NILSSON@Score.Stanford.EDU space plans
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 87 10:40:41 PDT
Date: Thu 23 Jul 87 10:33:46-PDT
From: Nils Nilsson <NILSSON@Score.Stanford.EDU>
Subject: space plans
To: faculty@Score.Stanford.EDU
Message-ID: <12320697689.26.NILSSON@Score.Stanford.EDU>
There has been a great deal of activity this summer on the problem
of who goes where in the North West Campus. Nothing has been
settled definitely except that "information sciences" is going
to be housed in the north and south excedra buildings and in
the CIS building and its planned extension. (Refer to the various
maps of the NWC plan to see where these buildings are; "information
sciences" refers to the entire CS Department, including all of
CSL, and the Information Systems Lab of EE.)
The purpose of this note is to solicit comments on a proposal for how
CS/CSL/ISL ought to be located in these buildings. It appears that the
North Excedra (Nox) Building will be built first. The university has
decided that Nox will also house some general-purpose large lecture
halls and classrooms (TV and non-TV). Reacting to the problems we have
had in mjh with lecture halls and classrooms being far away, I think
that's a good idea. My proposal for filling out the rest of Nox
is as follows:
1. KSL
2. Robotics
3. The rest of the AI and AI-related faculty (those not in KSL or robotics)
4. CSD-Computer Facilities
5. CSD Educational Affairs (will thus be close to classrooms)
Including the general classrooms, the total net square footage needed
by the above (as per my spreadsheets which many of you helped with)
is just slightly over what Nox is planned to have---within
experimental error.
My proposal for South Excedra (Sox) is as follows:
1. Part of CSL (the rest of it will be in CIS--who goes where
can be sorted out later)
2. The rest of the CSD faculty (i.e, foundations, sci.comp/comp math)
3. Chair's offices
4. CSD Administration
5. Computer Forum offices
6. Information Systems Lab
Here, the total footage needed is slightly under what Sox is
planned to have (more on that below).
Sox will probably be completed about a year after Nox.
The groupings have some nice features: all the AI folks are
together; there is some "theory" and some "practice" in each
building. Students would be distributed among the buildings
so as to be located near faculty advisors.
The university wants the Board of Trustees to approve the
Nox/Sox plan in concept this fall. The board will probably want
to know, generally, who is going where. After they approve, we
can get an architect started. At that stage, we'll definitely
need to know what the architect is designing for, and thus we'll
have to know pretty well who is going where. So, suggestions and
comments will be needed from y'all over the next few weeks.
One MAJOR PROBLEM: Some elements of the university (definitely not
including the Dean) want there to be a "watering hole" in the Sox
building to serve the entire region. Such facility would be a kind
of informal restaurant/meeting place to occupy something like
15,000 net square feet. I'm agin it because: 1) all and sundry
will be traipsing thru OUR building, making noise, disturbing
seminars/research, and 2) it takes up space that we might need
for other things. Maybe a watering hole is a good idea, but it
can be a good idea somewhere else. I would like to voice our
strong objection to such a plan to the Dean but will wait to do
so until you all have had a chance to respond. People who think
I should not so represent your sentiments to the Dean should
let me know before Aug 1!
-Nils
-------
∂23-Jul-87 1138 ullman@navajo.stanford.edu papers received
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 87 11:37:57 PDT
Received: by navajo.stanford.edu; Thu, 23 Jul 87 11:16:02 PDT
Date: Thu, 23 Jul 87 11:16:02 PDT
From: Jeff Ullman <ullman@navajo.stanford.edu>
Subject: papers received
To: nail@navajo.stanford.edu
The following are both from IBM, PO Box 704 Yorktown Hts. NY
(note the new PO Box for people at Hawthorne)
"On uniform implementation of optimizations for recursive queries"
D. Gangopadhyay
Uses counting to express recursions as one or more transitive closures,
then eliminates some of these TC's when arguments are bound.
With luck, you can then get rid ofthe "counting" and have an
optimized program for a particular query.
"Logic programming with sets"
G. Kuper
An update of the PODS 87 paper.
---jeff
∂23-Jul-87 1449 NILSSON@Score.Stanford.EDU soe actions
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 87 14:49:04 PDT
Date: Thu 23 Jul 87 14:42:12-PDT
From: Nils Nilsson <NILSSON@Score.Stanford.EDU>
Subject: soe actions
To: faculty@Score.Stanford.EDU
Message-ID: <12320742915.42.NILSSON@Score.Stanford.EDU>
The School of Engineering excom yesterday took the following actions
of interest to us:
1. The proposed appt. of Janos Komlos was approved. Some additional
polishing of the papers will be needed (I'm asking Anne Richardson
to coordinate this with Leo Guibas). In the meantime, Sol Feferman
in Math will confirm that H&S has approved and will call Janos with
the news that Stanford is making him an offer. We hope he will accept,
although the grapevine has it that Rutgers is also making him an
offer and that his wife may prefer the East. One budgetary problem:
although the provost has "loaned" us half a billet for our half of
the joint appt. with math, he hasn't given us any extra money.
2. The proposed appt. of Roland Glowinski (for the Sci. Computing/
Computational Math program) was "preliminarily approved." The papers
need much more work, and I will coordinate the final preparation of these
with the sabbaticalizing Gene Golub. This is a 1/2 in CSD---1/2 in Mech.
Engrg. appt. We cannot yet offer Glowinski the position, although I
will inform him that the process is moving along. The SOE excom was
emphatic in its insistence on seeing the final papers (Gene take note!)
before giving final approval.
-Nils
-------
∂23-Jul-87 1723 TAJNAI@score.stanford.edu The Forum Meets its One Megabuck Goal!!
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 87 17:23:53 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Thu, 23 Jul 87 17:14:06 PDT
Date: Thu 23 Jul 87 17:07:03-PDT
From: Carolyn Tajnai <TAJNAI@score.stanford.edu>
Subject: The Forum Meets its One Megabuck Goal!!
To: csd.list@score.stanford.edu, csl-everone@sierra.stanford.edu
Message-Id: <12320769284.41.TAJNAI@Score.Stanford.EDU>
Today we passed our million dollar goal for this fiscal year.
Congratulations to all of us!! We are the forum.
Advance notice of our celebration:
Friday, August 14, 4 p.m., ERL courtyard
Carolyn Tajnai
-------
∂24-Jul-87 1053 ULLMAN@score.stanford.edu [Stefano Ceri <CER@Score.Stanford.EDU>: EDBT call for papers]
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 87 10:52:51 PDT
Received: from Score.Stanford.EDU by navajo.stanford.edu with TCP; Fri, 24 Jul 87 10:44:15 PDT
Date: Fri 24 Jul 87 10:41:17-PDT
From: Jeffrey D. Ullman <ULLMAN@score.stanford.edu>
Subject: [Stefano Ceri <CER@Score.Stanford.EDU>: EDBT call for papers]
To: nail@navajo.stanford.edu
Message-Id: <12320961202.24.ULLMAN@Score.Stanford.EDU>
Mail-From: CER created at 23-Jul-87 18:02:08
Date: Thu 23 Jul 87 18:02:08-PDT
From: Stefano Ceri <CER@Score.Stanford.EDU>
Subject: EDBT call for papers
To: ullman@Score.Stanford.EDU
Message-ID: <12320779311.8.CER@Score.Stanford.EDU>
Jeff,
I enclose the Call for papers for the EDBT88 (Extending Database Technology)
to be held in Venice, most likely as first of an European Series that will
take place whenever VLDB is not in Europe, every other year. Could you
distribute this to the Nail network and also, perhaps, to Bboards that you
consider to be potentially interested? Thank you
Stefano Ceri
-----------------------------------------------------------------------
CALL FOR PAPERS
===============
INTERNATIONAL CONFERENCE
EXTENDING DATA BASE TECHNOLOGY
March 14-18, 1988
Cini Foundation, Venice, Italy
Organized by: Sponsored by: In Cooperation with:
IASI-CNR AICA IEEE
INRIA GI ACM
Pol. di Milano AFCET
Univ. Frankfurt BCS
THE CONFERENCE
--------------
EDBT 88 will be a forum for presentation of new results in
research, development, and applications of database technology. The
conference will favour the sharing of information between researchers
and practitioners and outline the future developments of database
systems and applications.
Tutorials will be offered in the first two days of the
Conference, and keynote speakers will be invited. The Conference and
Tutorials will be held at the Cini Foundation on S. Giorgio Island in
Venice. Venice will offer an exciting environment for social
activities.
TOPICS OF INTEREST
------------------
The EDBT 88 Conference will accept scientific and technical
papers on all areas of database development, but will primarily focus
on extensions of database technology in the following directions:
* Deductive databases and knowledge bases
* Heterogeneous and multimedia databases
* Object-oriented database systems and models
* Environments for database design and programming
* New applications of databases: engineering, office automation,
and software administration
* Distributed databases and database machines
* Performance issues and implementation techniques
INFORMATION FOR AUTHORS
-----------------------
Authors are requested to submit five copies (in English) of a
double-spaced manuscript up to 5000 words by October 10, 1987 to:
Prof. Joachim W. Schmidt
Universitat Frankfurt
Fachbereich Informatik
Dantestrasse 9
D 6000 Frankfurt 1
West Germany
tel.(49)-69-7988101
Short papers (up to 1000 words) describing ongoing projects are also
solicited; selected short papers will be included in the Proceedings
and be the basis of special discussion sections.
The preprints of the Proceedings will be distributed among the
Conference participants. The final version of the Conference
Proceedings will be edited and will be published by a major publishing
house.
IMPORTANT DATES
---------------
October 10, 1987 submission deadline (regular papers and short papers)
December 15, 1987 acceptance notification
February 1, 1988 camera-ready copies due
CONFERENCE ORGANIZATION
-----------------------
CONFERENCE CHAIRPERSON Stefano Ceri
(Universita di Modena and Politecnico di Milano)
PROGRAM COMMITTEE CHAIRPERSON
Joachim W. Schmidt
(Universitat Frankfurt)
PROGRAM COMMITTEE MEMBERS
S. Alagic (Jugoslavia) H.Kangassalo (Finland)
A.Albano (Italy) M.Missikof (Italy)
P.Apers (Netherlands) J.Mylopoulos (Canada)
M.Atkinson (G.Britain) E.Neuhold (F.R.Germany)
F.Bancilhon (France) J.M.Nicolas (F.R.Germany)
R.Bayer (F.R.Germany) A.Pirotte (Belgium)
C.Beeri (Israel) A.Reuter (F.R.Germany)
G.Bracchi (Italy) G.Schlageter (F.R.Germany)
M.L.Brodie (USA) A.Sernadas (Portugal)
J.Bubenko (Sweden) A.Solvberg (Norway)
S.Ceri (Italy) N.Spyratos (France)
Q.Chen (China) P.Stocker (G.Britain)
P.Dadam (F.R.Germany) K.Subieta (Poland)
R.Demolombe (France) B.Thalheim (D.R.Germany)
D.J.DeWitt (USA) D.C.Tsichritzis (Switzerland)
A.Furtado (Brasil) Y.Vassiliou (Greece)
G.Gardarin (France) G.Wiederhold (USA)
G.Gottlob (Austria) H.Williams (G.Britain)
L.A.Kalinichenko (USSR) C.Zaniolo (USA)
Y.Kambayashi (Japan) C.A.Zehnder (Switzerland)
ORGANIZING COMMITTEE CHAIRPERSON
M. Missikoff
(IASI-CNR)
ORGANIZING COMMITTEE MEMBERS
S.Ceri (Univ. di Modena and Politecnico di Milano)
G.Gardarin (Univ. of Paris and INRIA)
K.G.Jeffery (Rutherford Lab., G.Britain)
J.W.Schmidt (Universitat Frankfurt)
TREASURER P. Atzeni
(IASI-CNR)
INDUSTRIAL EXHIBITIONS COORDINATOR
A. D'Atri
(Univ. di L'Aquila e Univ. di Roma ``La Sapienza'')
US COORDINATOR C. Zaniolo
(MCC USA)
NOTES: For further organization information on EDBT 88 refer to:
Michele Missikoff
IASI-CNR
Viale Manzoni 30
00185 ROMA
Italy
tel. (39)-6-770031
Conference Secretariat:
CRAI
Via Tevere 15
00198 ROMA
Italy
tel. (39)-6-852500
--END
-------
-------
-------
∂24-Jul-87 1904 @score.stanford.edu:SUBRAMANIAN@SUMEX-AIM.STANFORD.EDU Request for nominations
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 87 19:04:18 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Fri, 24 Jul 87 18:53:47 PDT
Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Fri 24 Jul 87 18:44:43-PDT
Date: Fri, 24 Jul 87 18:29:08 PDT
From: Devika Subramanian <SUBRAMANIAN@sumex-aim.stanford.edu>
Subject: Request for nominations
To: csd-list@score.stanford.edu
Message-Id: <12321046370.60.SUBRAMANIAN@SUMEX-AIM.STANFORD.EDU>
Nominations are invited, especially from students, for the Thirteenth
George E. Forsythe Memorial Award and the Third Computer Science
Department Service Award. Each award is given annually by the
Computer Science Department, following the recommendations of a
committee composed of the past winners.
The Forsythe Award recognizes outstanding student contributions to the
teaching of computer science at Stanford. The award criteria guidelines
require that a recipient exhibit continued involvement as well as
excellent achievement in the field of teaching. Recent winners of the
Forsythe Award have been Veronica Falcao, Oren Patashnik, Simran Singh
and Devika Subramanian.
The Service Award, initiated two years ago, recognizes outstanding student
contributions to the well-being of the department in non-academic areas.
Previous Winners are Joe Weening, Jeff Mogul and Peter Karp.
Please mail your Forsythe Award nominations to Subramanian@Sumex
and your Service Award nominations to Pkarp@Sumex. Please
include with your nomination an explanation of how your nominee fulfills
these requirements. The deadline for nominations is August 10.
Thank you,
The Forsythe Award Committee
The Service Award Committee
-------
∂25-Jul-87 1355 NILSSON@Score.Stanford.EDU Research Centers
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 25 Jul 87 13:55:33 PDT
Date: Sat 25 Jul 87 13:48:50-PDT
From: Nils Nilsson <NILSSON@Score.Stanford.EDU>
Subject: Research Centers
To: faculty@Score.Stanford.EDU
cc: levinthal@Sierra.Stanford.EDU
Message-ID: <12321257486.15.NILSSON@Score.Stanford.EDU>
Following on the heels of the NSF Engineering Research Centers will be
various announcements for similar centers coming from NASA, more from
NSF, Dept. of Commerce, etc. The topic of how Stanford can best respond
was discussed at the recent SOE xcom retreat.
Although there is considerable sentiment for continuing our usual
exuberant entrepreneurial spirit, many of us feel that we could harm
our overall efforts if centers with overlapping research agendas
are proposed by different Stanford faculty groups. (Since one
of the reasons for the centers is to encourage interdisciplinary
research among groups, the natural reaction of an agency receiving
different but related proposals from different Stanford groups will
be to ask "Why didn't these folks get together to make a really
strong proposal?")
Therefore, Dean Gibbons (backed by the xcom) is announcing the following
policy: People who intend to write a "center proposal" should send a
short description of their intention through their department chair to
Elliott Levinthal (Assoc. SOE Dean for Research) as soon as practicable
and sufficiently far in advance of actual proposal writing to enable
Elliott to introduce potentially overlapping teams to each other. Note
that the policy is not intended to force shotgun marriages or to stifle
proposals. Instead, we are to regard Elliott as a kind of "dating
bureau."
-Nils
-------
∂27-Jul-87 0126 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #48
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 87 01:26:14 PDT
Date: Sun 26 Jul 1987 15:03-PDT
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #48
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Monday, 27 Jul 1987 Volume 5 : Issue 48
Today's Topics:
Query - Blackboard Architectures & CHAT
----------------------------------------------------------------------
Date: Wed 22 Jul 87 11:52:28-CDT
From: Olivier J. Winghart <CS.WINGHART@R20.UTEXAS.EDU>
Subject: Blackboard architectures in Prolog
I am looking for natural ways of implementing a blackboard
architecture in Prolog. Has anyone already thought about this, and are
there any papers that I could look at ? I would appreciate any
pointer.
-- Olivier
------------------------------
Date: Mon, 20 Jul 87 13:48 EDT
From: McHale@RADC-MULTICS.ARPA
Subject: Help with CHAT
We are working with topographical maps that have information such as
towns, rivers, airports, railroads, roads, dams, bridges,... This has
us looking at a much finer grain data base than CHAT did. We modified
the template file for the resulting new semantic hierarchy.
We originally intended to extend CHAT to handle pronomial references,
ellipsis, etc. however, we ran into trouble just handling conjunctions
and adjectives. The query 'is Tokyo european?' is answered 'yes'. This
may be a problem with my converting from Dec-10 prolog to Quintus, but
I don't think so. We fixed the grammar for this particular problem,
(the only change we've made to the grammar) but the system doesn't handle
it correctly later on (in Clausify).
I'll send you a more detailed outline of changes we've made. Another
thing that I would like to know more about is the ND table. I know it is
important for query optimization but have no idea on how to select proper
values for it.
We'd appreciate any pointers you can give.
-- Mike
------------------------------
Date: Mon, 20 Jul 87 15:30:52 EDT
From: mchalem@radc-lonex.arpa
Subject: CHAT
Chat-80 is a PROLOG-based front-end natural language interface to
a worldwide database. It was written in partial fulfillment of
Fernando Pereira's PhD. thesis at the University of Edinburgh for the
degree of Doctor of Philosophy in Artificial Intelligence. Michael
McHale, John Crowter, and Mary Ann Huntley of RADC are working in
conjunction with Dr. Richard Kittredge, a linguist from the University
of Montreal and the Odyssey Research Corporation in Ithaca, to extend
Chat-80.
The worldwide database has been replaced with the database
Michael Hilton is using for his simulation, and includes parts of West
Germany, East Germany, and Czechoslovakia. Scott Gregory wrote LISP
routines which convert the database from ASCII to PROLOG. It is hoped
that the modified Chat will serve as the natural language interface to
the aforementioned simulation.
Chat-80 takes as input a natural language query, such as, What is
the capital of the United States. The query is first syntactically
parsed, and categorized as being one of four basic types of queries:
declarative, yes/no, wh-type, or imperative. This parse is then sent
off to semantics, where it encounters query planning and then query
evaluation. In this (not so well understood) stage of processing, the
query is mathematically optimized such that the most efficient access
to the database is performed. The database is then searched for the
answer, which is printed.
Modifications to CHAT-80
Many people suggested that Chat-80's grammar should be changed as
little as possible due to its extreme complexity and nice
organization. We therefore have been extensively modifying the
lexicon. In addition to addding new words, we have added a clever
feature to handle verbs. Previously, to add a verb and all its
tenses, six new entries had to be added to the lexicon. Now we have a
rule whereby we add the verb in only two places, and the tenses of the
verb are automatically created and added to the lexicon. It is also
necessary to modify the semantic dictionary, as well as the domain
dependent rule base when adding a new item to the syntactic
dictionary. It is interesting to note that although a complete
syntactic parse is made before entering semantic interpretation of the
input, some key words are coded directly into the grammar, i.e.,
wh-terms: where and what.
Preprocessing
In an effort to utilize as much of Chat-80 as possible without
changing the grammar, we decided to preprocess the input query. In
this way, we massage the query into one which Chat-80 (hopefully)
understands and can answer. The preprocessor contains several steps
in accordance with several problems we have encountered:
Imperatives
We want to be able to handle imperatives, such as Show me road
7, and Please show me the railroads. (This is with the intent that
Jean Carletta's graphics routines will be utilized. When the user
asks to see the railroads, for instance, the railroads on the screen
will be highlighted.) We thus look at the input query, and try to
match the beginning of the query with the three types of imperatives
our system can handle: show, show me, and please show me. Upon
finding that the input starts with one of these three phrases, the
query is transformed into one of the form: Where is ..., and this new
query is handed to Chat, as if it were the original query.
Compound words
Compound words such as Erfurt_North (anything with an underscore in
it) and type one, type two, and type three (words which have a special
meaning when used together) posed another problem. We have made it
possible to type a compound word as either having an underscore or not.
Also, type one, type two, and type three now are treated as a single
entity. Compound nouns were also problematic; i.e., road 7, where both
road and 7 are considered nouns. We have enabled the grammar to handle
double nouns by classifying them as a special type of compound word.
Synonyms
We wanted equivalent words to have equivalent meanings. Ergo, we
have made the following synonyms in our system:
waterway = river = stream = brook = creek
town = city
road = roadway = route
Spelling Checker
Due to the complexity of the spelling of the proper nouns in the
database, as well as the human error of misspellings and typographical
errors, a pattern matching spelling checker is implemented. If a word
in the input is not in the dictionary, then the user is informed, the
closest match replaces the unknown word, and the query proceeds as
usual.
"What is proper noun" query
It is helpful for the user to ask the system, for example,
What is Apolda. The system should then reply a town. However, the
response supplied by Chat was Apolda. Similarly, when asked what 7
was, the system replied 7, when what was intended was a road. We thus
needed a way to solve this problem. Our solution was to turn to the
preprocessor, which will look at the input query, and determine if it
is of the form "What is proper noun." If it is, then we check to see
what kind of thing the proper noun is during the logic phase of the
query processing.
Single noun phrase queries
It is desirous to have the ability to input a single noun
phrase such as Merseburg or road 7, and have Jean's system highlight
the appropriate area on the map. Thus, we needed to be able to parse
single noun phrases. Again we turned to the preprocessor to solve
this problem. If the input query contains a single noun phrase, then
we transform it to the form: "Where is np," and the process proceedes
as usual.
semantic hierarchy
We found it necessary to change the semantic hierarchy in
accordance with the information in the specialized database with which
we are working. The new hierarchy is as follows:
feature
area point line
block town land water
country heliport
terrain bridge
wetland dam road river
mountain obstruction railroad
airstrip power line
border
Test file
A test file was created which contains several queries which
currently work on our system. This was added so that whenever we add
a new feature to the system, we can execute this file to see if the
modification creates errors elsewhere.
Help file
David Warhoftig has created a help file to orient new users to the
system. It is composed of three parts:
Welcome for new users
This introduces the user to Chat; i.e., what it is, what it does, and
how to use it.
Sample queries and responses
Similar to the module in Chat-80, this facility aids the user in
formulating a query which the system can understand.
Helpful hints and reminders
Suggestions are offered on how to represent the input; i.e.,
the user is informed that the query need not start with a capital
letter, nor does it need to end with a question mark. Also, commas in
the input are ignored, and a spelling checker is implemented.
Current problems
Distance
We are currently examining distance queries, such as 'How far is Goslar
from Merseburg', and 'What is the distance between Apolda and Artern'.
Jean Carletta has written LISP routines to compute distances, and we will
either use them or modify them to suit our needs. In either case, they
must be translated to Prolog.
Pronomial Reference
We would like for the user to be able to use pronouns, and have them
refer to the response from the previous query.
Difficulty with adjectives
We have found particular difficulty in adding adjectives to Chat-80. We
feel that the implementation of adjectives may be somewhat weak, as when
we asked the original Chat-80 if Tokyo is European, the reply was 'yes'. We
would like to have the capacity to ask queries involving the adjective
mountainous.
Remarks
In light of the fact that a great deal of effort was expended to gain an
overall feel for the code, we feel that we have been making steady progress
in modifying Chat-80.
------------------------------
End of PROLOG Digest
********************
∂28-Jul-87 0122 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #49
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 87 01:22:32 PDT
Date: Mon 27 Jul 1987 20:20-PDT
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #49
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Tuesday, 28 Jul 1987 Volume 5 : Issue 49
Today's Topics:
Query - Representation,
Implementation - CProlog Parser,
LP Library - WARPLAN Update
----------------------------------------------------------------------
Date: Mon, 20 Jul 87 16:58:51 MET
From: norbert%germany.csnet@RELAY.CS.NET
Subject: Feature (!) in C-Prolog parser
The 'bug' mentioned in the latest issue of the Prolog Digest is one of
the numerous undocumented features of C-Prolog:
If the parser encounters a sequence of a token ',' and a token
'..' in a place where the list separator '|' might be useful,
the sequence is interpreted as that separator. I suppose this was
intended to help people with non-american keyboards, that can't enter
'|' or will see another character instead of it (e.g. in German
'ASCII' the same code is used for an 'o', decorated with two dots). In
fact, it does not help, because nobody knows about it.
-- Norbert Lindenberg
Universitaet Karlsruhe, West Germany
------------------------------
Date: 15 Jul 87 20:09:05 GMT
From: uunet!mnetor!yetti!asst-jos@seismo.css.gov
Subject: Request for help with C-prolog program
I have a Prolog question that I'm hoping someone might be able to help
me with. I am using C-Prolog version 1.5 on a Vax/VMS 8600. C-Prolog
assigns a unique system name (or internal representation) to a
variable that is composed of the underscore, followed by a sequence of
digits. To illustrate this I include a sample session with the Prolog
interpreter using a Vax/VMS 8600).
$ prolog
C-Prolog version 1.5
| ?- [user].
| go(A,B):-read(A), read(B).
| Exit
user consulted 104 bytes 2.000041e-03 sec.
yes
| ?- go(LIST1,LIST2).
|: [A, B, C].
|: A=32, B=45.
LIST1 = [_6,_7,_8]
_15=32,19=45
yes
| ?- Exit
[ Prolog execution halted ]
Note that the internal representation of variable A in LIST1, (_6), is
different from the internal representation of variable A in LIST2,
(_15), and that the internal representation of variable B in LIST1,
(_7), is different from the internal representation of variable B in
LIST2, (_19), because they were read separately.
My problem is that I would like to read the same variables from two
different files, and would like to know if it is possible to assure
that they are read as the same variable. To explain this better, I'll
give an example of what I would like to achieve.
FILE-1 contains:
[A, B, C].
FILE-2 contains:
A = 3, B = C + A
I would like assert the following predicate:
sample_predicate:- see('FILE-1'), read(VECTOR), seen,
see('FILE-2'), read(TEST),seen,
assert(( is_true(VECTOR):-TEST )).
The goal is to be able to assign values to the variables in VECTOR,
and then execute 'is_true', so that it will return a value of 'true'
iff TEST is true.
The problem is that the variable 'A' read from FILE-1 is a different
variable from the variable 'A' read from FILE-2, as seen in the sample
prolog code above. How can I make the A read from FILE-1 be the same A
read from FILE-2?
-- Jeff Klein
York University.
------------------------------
Date: Sun 26 Jul 87 15:22:40-PDT
From: Chuck Restivo <Restivo@Sushi.Stanford.EDU>
Subject: WARPLAN
Prof. D.H.Warren posted a copy of WARPLAN and sample STRIPS world.
Unlike the last version, this one works properly.
See SUSHI.STANFORD.EDU:PS:<Prolog>WARPLAN.PL . Anonymous FTP should
work, if you cannot FTP, post a note to PROLOG-REQUEST at this site.
-- Chuck
------------------------------
End of PROLOG Digest
********************
∂28-Jul-87 1914 SCHAFFER@Sushi.Stanford.EDU Last 2 TheoryNet Messages
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 87 19:14:02 PDT
Date: Tue 28 Jul 87 19:08:32-PDT
From: Alejandro Schaffer <SCHAFFER@Sushi.Stanford.EDU>
Subject: Last 2 TheoryNet Messages
To: aflb.tn@Sushi.Stanford.EDU
Message-ID: <12322102118.8.SCHAFFER@Sushi.Stanford.EDU>
The problem with the mailer has been circumvented, although the
"bug" persists. Here are the last 2 messages that some people never
got. I have truncated the headers a bit.
Alejandro
12-Jul-87 18:27:07-PDT,3540;000000000000
Return-Path: <THEORYNT%YKTVMZ.BITNET@forsythe.stanford.edu>
Date: Fri 10 Jul EDT 1987 16:15
From: mihalis%btl.csnet@relay.cs.net
Subject: PODS88 Call for Papers
Reply-To: THEORYNT%YKTVMZ.BITNET@forsythe.stanford.edu
Apparently-To: aflb.tn@SUSHI.STANFORD.EDU
-------------------------------------------------------------------------
CALL FOR PAPERS
Seventh ACM SIGACT-SIGMOD-SIGART Symposium on
PRINCIPLES OF DATABASE SYSTEMS
Austin, Texas, March 21-23, 1988
The conference will cover new developments in both the theoretical and
practical aspects of database and knowledge-base systems. Papers are
solicited which describe original and novel research about the theory,
design, specification, or implementation of database and knowledge-base
systems.
Some suggested, although not exclusive, topics of interest are:
architecture, concurrency control, database and expert systems, database
machines, data models, data structures for physical implementation, deductive
databases, dependency theory, distributed systems, incomplete information,
user interfaces, performance evaluation, physical and logical design,
query languages, query processing, recursive rules, spatial and temporal data,
statistical databases, and transaction management.
You are invited to submit ten copies of a detailed abstract (not a complete
paper)
to the program chairman:
Mihalis Yannakakis
Room 2C-319
AT&T Bell Laboratories
600 Mountain Avenue
Murray Hill, NJ 07974
Submissions will be evaluated on the basis of significance, originality,
and overall quality. Each abstract should 1) contain enough information
to enable the program committee to identify the main contributions of the work;
2) explain the importance of the work - its novelty and its practical or
theoretical relevance to database and knowledge-base systems; and 3) include
comparisons with and references to relevant literature. Abstracts should be no
longer than ten double-spaced pages. Deviations from these guidelines may affect
the program committee's evaluation of the paper.
Program Committee
Serge Abiteboul Alberto Mendelzon
Krzysztof Apt Dale Skeen
Philip Bernstein Victor Vianu
Paris Kanellakis Mihalis Yannakakis
David Maier
The deadline for submission of abstracts is October 9, 1987.
Authors will be notified of acceptance or rejection by December 8, 1987.
The accepted papers, typed on special forms, will be due at the above address
by January 8, 1988. All authors of accepted papers will be expected to sign
copyright release forms. Proceedings will be distributed at the conference,
and will be subsequently available for purchase through ACM.
General Chairman: Local Arrangements:
Avi Silberschatz Chris Edmondson-Yurkanan
Dept. of Computer Sciences Dept. of Computer Sciences
Univ. of Texas at Austin Univ. of Texas at Austin
Austin, Texas 78712 Austin, Texas 78712
------
21-Jul-87 10:09:46-PDT,2229;000000000000
Return-Path: <THEORYNT%YKTVMZ.BITNET@forsythe.stanford.edu>
Date: Tue 21 Jul EDT 1987 12:07
From: Martin Tompa <tompa@ibm.com>
Subject: LOGCFL
Reply-To: THEORYNT%YKTVMZ.BITNET@forsythe.stanford.edu
Apparently-To: aflb.tn@SUSHI.STANFORD.EDU
Using a method very similar to Neil Immerman's, I have a proof that
LOGCFL is closed under complementation. The main difference is that,
instead of counting the number of configurations reachable from the
initial configuration, it seems that one must count the number of
realizable pairs of surface configurations. This requires a little more
bookkeeping than Neil's proof, but the outline is exactly the same. For
example, in order to check whether (u,v) is realizable by a computation
of length at most d+1, given the number of pairs realizable by
computations of length at most d, one of the things that must be done is
the following: Cycle through all possible pairs (h,i) counting those
that are realizable by some computation of length b at most d. For each
such (h,i), cycle through all possible pairs (j,k) counting those that
are realizable by some computation of length c at most d. For each such
(j,k), check whether u=h, i=j, k=v, and b+c is at most d+1.
For pebbling enthusiasts, here is a curious consequence. One can define
a LOGCFL hierarchy whose SIGMA1 is LOGCFL, and whose SIGMA(i+1) is
LOGCFL with an oracle for SIGMAi. It turns out that SIGMAi is
equivalently the set of languages recognizable by polynomial size
uniform circuits that can be pebbled in the dual 2-person pebble game
with constant pebbles, O(log n) time, and i-1 role switches. Of course
this hierarchy collapses to SIGMA1 (perhaps the shortest-lived of all
hierarchies). As a consequence, 0 role switches are as powerful as any
constant number.
-------
∂28-Jul-87 1922 SCHAFFER@Sushi.Stanford.EDU Next AFLB
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 87 19:22:33 PDT
Date: Tue 28 Jul 87 19:11:34-PDT
From: Alejandro Schaffer <SCHAFFER@Sushi.Stanford.EDU>
Subject: Next AFLB
To: aflb.all@Sushi.Stanford.EDU
Message-ID: <12322102670.8.SCHAFFER@Sushi.Stanford.EDU>
6-August-1987: Anil Gangolli (Stanford)
Generating Random Combinatorial Objects with Random Walks
Suppose we have a set S of objects from which we wish to choose a
member approximately uniformly at random, that is, each with
probability 1/|S|, or nearly so. Even given a source of unbiased
independent random bits, it may not be obvious how to do this. We may
not even know precisely what |S| is. Recent results by Broder on
approximating the permanent, and work in progress by Diaconis and
Gangolli on problems related to chi-squared testing use "random walks"
on relevant sets S to choose elements uniformly or nearly uniformly at
random.
We'll discuss how this approach works, some of the questions which arise
naturally when one takes it, and some techniques one can use for answering
these questions.
Only a basic background in discrete probability, and some linear algebra
will be assumed.
***** Time and place: August 6, 12:30pm in MJ352 (Bldg. 460) *****
-------
∂29-Jul-87 0011 MAVARDI%WEIZMANN.BITNET@forsythe.stanford.edu Call
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 87 00:11:44 PDT
Received: from Lindy.Stanford.EDU by navajo.stanford.edu with TCP; Wed, 29 Jul 87 00:06:32 PDT
Received: by lindy.stanford.edu; Wed, 29 Jul 87 00:08:59 PDT
Received: by Forsythe.Stanford.EDU; Wed, 29 Jul 87 00:08:14 PDT
Received: by WEIZMANN (Mailer X1.24) id 1741; Wed, 29 Jul 87 09:50:56 +0300
Resent-Date: Wed, 29 Jul 87 09:50:07 +0300
Resent-From: Moshe Vardi <MAVARDI%WEIZMANN.BITNET@forsythe.stanford.edu>
Resent-To: nail@navajo.stanford.edu
Received: from um.cc.umich.edu by IBM.COM on 07/28/87 at 05:45:44 PDT
Received: by umix.cc.umich.edu (5.54/umix-2.0)
id AA00305; Tue, 28 Jul 87 08:47:25 EDT
Date: Tue, 28 Jul 87 08:40:54 EDT
From: Yuri_Gurevich%um.cc.umich.edu@forsythe.stanford.edu
To: vardi@ibm.com
Message-Id: <2189752@um.cc.umich.edu>
Subject: Call
CALL FOR PAPERS
THIRD ANNUAL SYMPOSIUM ON
LOGIC IN COMPUTER SCIENCE
5-8 July 1988
University of Edinburgh, Edinburgh, Scotland
Concepts and methods from Logic are influential throughout Computer
Science. The Annual IEEE Symposium on Logic in Computer Science (LICS)
aims to attract broad participation of Computer Scientists, whose design
or research activities involve Logic, and Logicians interested in Computer
Science. Suggested (but not exclusive) topics of interest include:
abstract data types, computer theorem proving, concurrency, data base
theory, knowledge representation, finite model theory, lambda and
combinatory calculi, logic programming, modal and temporal logics,
program logic and semantics, software specification, types and categories,
constructive mathematics, verification.
PROGRAM COMMITTEE: M. Dezani, Y. Gurevich (chair), J. Halpern, C.A.R.
Hoare, G. Huet, P. Kanellakis, J.-L.Lassez, J. Mitchell, R. Platek,
G. Plotkin, S. Rosenschein, P. Sistla, J. Tiuryn, M. Wand
PAPER SUBMISSION: Send 14 copies of an extended abstract to the
program chairman:
Yuri Gurevich - LICS (313) 971-2652
Electrical Engineering and Yuri_Gurevich@um.cc.umich.edu
Computer Science Department
University of Michigan
Ann Arbor, Michigan 48109-2122
The package must be airmail postmarked by 27 NOVEMBER 1987 or received by
4 DECEMBER 1987. The abstract should be clearly written and provide
sufficient detail to allow the program committee to assess the merits of
the paper. References and comparisons with related work should be
included where appropriate. The entire extended abstract should not
exceed 10 double-spaced pages in 10 or 12-point font. Late abstracts or
those departing significantly from these guidelines run a high risk of
not being considered. If a copier is not available to the author, a
single copy of the abstract will do.
The authors will be notified of acceptance or rejection by 27 JANUARY
1988. Accepted papers, typed on special forms for inclusion in the
symposium proceedings, will be due 14 MARCH 1988.
The symposium is sponsored by the IEEE Computer Society, Technical
Committee on Mathematical Foundations of Computing , and the University
of Edinburgh, in cooperation with ACM SIGACT, ASL, and EATCS.
ORGANIZING COMMITTEE: J. Barwise, W. Bledsoe, A. Chandra (chair),
E. Dijkstra, E. Engeler, J. Goguen, D. Gries, D. Kozen, Z. Manna,
A. Meyer, R. Parikh, G. Plotkin, D. Scott
GENERAL CHAIRMAN: LOCAL ARRANGEMENTS:
Ashok K. Chandra George Cleland
IBM T. J. Watson Research Center Department of Computer Science
P.O. Box 218 The King's Buildings
Yorktown Heights, NY 10598 University of Edinburgh
(914) 945-1752 Edinburgh EH9 3JZ, SCOTLAND
ashok@ibm.com 011 44 31 667 1081 ext. 2775
glc%lfcs.edinburgh.ac.uk@ucl-cs.arpa
∂29-Jul-87 0141 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #50
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 87 01:41:38 PDT
Date: Tue 28 Jul 1987 20:11-PDT
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #50
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Wednesday, 29 Jul 1987 Volume 5 : Issue 50
Today's Topics:
Implementation - History & Variables,
Announcement - EDBT Call for Papers
----------------------------------------------------------------------
Date: Tue, 28 Jul 87 09:44:57 PDT
From: Fernando Pereira <pereira@stinson.ai.sri.com>
Subject: C-Prolog questions
The notation [X,..L] as an alternative to [X|L] is accepted by C-Prolog
for backwards compatibility with some old DEC-10 Prolog programs. The
,.. notation was originally used in DEC-10 Prolog to cope with the reduced
character set of upper-case only terminals (yes, there were such terminals
around back in 1975/76 when Dave Warren started the DEC-10 Prolog compiler
at Edinburgh).
Jeff Klein's problem with variables accross multiple calls to read/1
can be solved in many different ways. The nature of a Prolog variable
is to be unique to a particular term (eg. a clause) read by read/1,
so his problem is only to be expected (it has nothing to do with
the internal representations of variables), which in fact are ephemeral
(_33 is an identifier constructed on the fly by write/1 and has no
persistence beyond a single call to write/1 -- or even less in Prologs
with GC!). The simplest way to solve the problem is to use read/2
in Prolog systems that have it (eg. C-Prolog 1.5.edai), which returns
as its 2nd argument an association list between variable names
(atoms) and variables. For example
?- read(Term, Vars).
|: [A, B, C].
Term = [_11, _22, _33]
Vars = ['A'=_11, 'B'=_22, 'C'=_33]
If your Prolog does not provide this facility, you can get it from the
public domain reader due to Richard O'Keefe. When in doubt, look in
the library...
-- Fernando Pereira
------------------------------
Date: Fri 24 Jul 87 10:41:17-PDT
From: Jeffrey D. Ullman <ULLMAN@score.stanford.edu>
Subject: EDBT call for papers
Call for Papers
===============
International Conference
Extending Data Base Technology
March 14-18, 1988
Cini Foundation, Venice, Italy
Organized by: Sponsored by: In Cooperation with:
IASI-CNR AICA IEEE
INRIA GI ACM
Pol. di Milano AFCET
Univ. Frankfurt BCS
The Conference
EDBT 88 will be a forum for presentation of new results in
research, development, and applications of database technology. The
conference will favour the sharing of information between researchers
and practitioners and outline the future developments of database
systems and applications.
Tutorials will be offered in the first two days of the
Conference, and keynote speakers will be invited. The Conference and
Tutorials will be held at the Cini Foundation on S. Giorgio Island in
Venice. Venice will offer an exciting environment for social
activities.
Topics of Interest
The EDBT 88 Conference will accept scientific and technical
papers on all areas of database development, but will primarily focus
on extensions of database technology in the following directions:
* Deductive databases and knowledge bases
* Heterogeneous and multimedia databases
* Object-oriented database systems and models
* Environments for database design and programming
* New applications of databases: engineering, office automation,
and software administration
* Distributed databases and database machines
* Performance issues and implementation techniques
Information for Authors
Authors are requested to submit five copies (in English) of a
double-spaced manuscript up to 5000 words by October 10, 1987 to:
Prof. Joachim W. Schmidt
Universitat Frankfurt
Fachbereich Informatik
Dantestrasse 9
D 6000 Frankfurt 1
West Germany
tel.(49)-69-7988101
Short papers (up to 1000 words) describing ongoing projects are also
solicited; selected short papers will be included in the Proceedings
and be the basis of special discussion sections.
The preprints of the Proceedings will be distributed among the
Conference participants. The final version of the Conference
Proceedings will be edited and will be published by a major publishing
house.
Important Dates
October 10, 1987 submission deadline (regular papers and short papers)
December 15, 1987 acceptance notification
February 1, 1988 camera-ready copies due
Conference Organization
Conference Chairperson Stefano Ceri
(Universita di Modena and Politecnico di Milano)
Program Committee Chairperson
Joachim W. Schmidt
(Universitat Frankfurt)
Program Committee Members
S. Alagic (Jugoslavia) H.Kangassalo (Finland)
A.Albano (Italy) M.Missikof (Italy)
P.Apers (Netherlands) J.Mylopoulos (Canada)
M.Atkinson (G.Britain) E.Neuhold (F.R.Germany)
F.Bancilhon (France) J.M.Nicolas (F.R.Germany)
R.Bayer (F.R.Germany) A.Pirotte (Belgium)
C.Beeri (Israel) A.Reuter (F.R.Germany)
G.Bracchi (Italy) G.Schlageter (F.R.Germany)
M.L.Brodie (USA) A.Sernadas (Portugal)
J.Bubenko (Sweden) A.Solvberg (Norway)
S.Ceri (Italy) N.Spyratos (France)
Q.Chen (China) P.Stocker (G.Britain)
P.Dadam (F.R.Germany) K.Subieta (Poland)
R.Demolombe (France) B.Thalheim (D.R.Germany)
D.J.DeWitt (USA) D.C.Tsichritzis (Switzerland)
A.Furtado (Brasil) Y.Vassiliou (Greece)
G.Gardarin (France) G.Wiederhold (USA)
G.Gottlob (Austria) H.Williams (G.Britain)
L.A.Kalinichenko (USSR) C.Zaniolo (USA)
Y.Kambayashi (Japan) C.A.Zehnder (Switzerland)
Us Coordinator C. Zaniolo
(MCC USA)
Notes: For further organization information on EDBT 88 refer to:
Michele Missikoff
IASI-CNR
Viale Manzoni 30
00185 ROMA
Italy
tel. (39)-6-770031
Conference Secretariat:
CRAI
Via Tevere 15
00198 ROMA
Italy
tel. (39)-6-852500
------------------------------
End of PROLOG Digest
********************
∂29-Jul-87 1320 OKUNO@SUMEX-AIM.STANFORD.EDU Explorer during my vacation (Aug. 1 ~ 23)
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 87 13:20:42 PDT
Date: Wed, 29 Jul 87 13:20:25 PDT
From: Hiroshi "Gitchang" Okuno <Okuno@SUMEX-AIM.STANFORD.EDU>
Subject: Explorer during my vacation (Aug. 1 ~ 23)
To: commUNICATIONS@SUMEX-AIM.STANFORD.EDU, aap@SUMEX-AIM.STANFORD.EDU
Organization: Knowledge Systems Laboratory
Group: Heuristic Programming Project
Project: Advanced Architectures Project
Address: 701 Welch Road, Building C, Palo Alto, CA 94304-1703
Phone: +1 (415)725-4854
Message-ID: <12322300889.33.OKUNO@SUMEX-AIM.STANFORD.EDU>
I'll be out of town from August 1st to 23rd. Please feel free to use my
Explorer (X10) and terminal (VT100 compatible). If you want to use
them, ask Nancy or Flora to unlock the door.
I'm going to Yellowstone, Canadian Rockies and Victoria by car but
the itinerary is not fixed yet. I prefer adaptive scheduling.
- Gitchang -
-------
∂29-Jul-87 1420 BSCOTT@Score.Stanford.EDU Yvette Sloan
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 87 14:16:11 PDT
Date: Wed 29 Jul 87 14:13:12-PDT
From: Betty Scott <BSCOTT@Score.Stanford.EDU>
Subject: Yvette Sloan
To: Faculty@Score.Stanford.EDU, Staff@Score.Stanford.EDU
cc: BScott@Score.Stanford.EDU
Message-ID: <12322310498.27.BSCOTT@Score.Stanford.EDU>
I am pleased to announce that Yvette Sloan began work as Department Resources
Manager in CS this morning. Yvette has worked in Industrial Engineering for
a good many years, so she is familiar with some of the problems we have con-
cerning space, phones and personnel. She will divide her time between CS
and IE through next Tuesday, beginning here full time on Wednesday, August 5.
If you have not met Yvette, please stop by MJH 215 to introduce yourself and
to welcome her to the Department.
Betty
-------
∂29-Jul-87 1450 AAAI-OFFICE@SUMEX-AIM.STANFORD.EDU [AAAI <AAAI-OFFICE@SUMEX-AIM.STANFORD.EDU>: Committee involvement]
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 87 14:50:10 PDT
Date: Wed, 29 Jul 87 14:49:48 PDT
From: AAAI <AAAI-OFFICE@SUMEX-AIM.STANFORD.EDU>
Subject: [AAAI <AAAI-OFFICE@SUMEX-AIM.STANFORD.EDU>: Committee involvement]
To: officers: ;
Telephone: (415) 328-3123
Postal-Address: 445 Burgess Drive, Menlo Park, CA 94025
Message-ID: <12322317162.95.AAAI-OFFICE@SUMEX-AIM.STANFORD.EDU>
Somehow the bottom of the previous msg was cut off. Here is the complete
msg.
Claudia
---------------
Mail-From: AAAI-OFFICE created at 29-Jul-87 14:38:20
Date: Wed, 29 Jul 87 14:38:20 PDT
From: AAAI <AAAI-OFFICE@SUMEX-AIM.STANFORD.EDU>
Subject: Committee involvement
To: officers: ;
cc: aaAI-OFFICE@SUMEX-AIM.STANFORD.EDU
Telephone: (415) 328-3123
Postal-Address: 445 Burgess Drive, Menlo Park, CA 94025
Message-ID: <12322315074.95.AAAI-OFFICE@SUMEX-AIM.STANFORD.EDU>
The AAAI has several standing and ad hoc committees which are to be composed of
two or more councilors or officers. In order to fulfill this legislative
requirement, we would kindly request your involvement in the following
committees:
* Publications
* Conference
* Finance
* Symposium
* Scholarship
* Tutorials
Later on as we begin to investigate the organization of a post-doc fellowship
program, we will request your assistance.
If you desire more information about the functions and duties associated with
these committees, I will be more than happy to provide it for you.
We look forward to hearing from you soon.
Sincerely,
Claudia
-------
∂30-Jul-87 1416 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #51
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 87 14:16:39 PDT
Date: Thu 30 Jul 1987 11:59-PDT
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #51
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Thursday, 30 Jul 1987 Volume 5 : Issue 51
Today's Topics:
Query - Naive Reverse & Database Recognition,
Implementation - Interfile Scoping
----------------------------------------------------------------------
Date: 28 Jul 87 22:12:01 GMT
From: MorrisseyKA <ihnp4!drutx!druhi!kam@ucbvax.Berkeley.EDU>
Subject: Naive Reverse
Here is a naive (:-) question:
What is the formula for determining the number of LIs needed
to reverse a list of length N, using the following definition?
nairev([],[]).
nairev([X|Xs],Zs) :- nairev(Xs,Ys), append(Ys,[X],Zs).
append([],L,L).
append([X|L1],L2,[X|L3]) :- append(L1,L2,L3).
It seems that the answer should be easy to determine, but I'm having a
heck of a time coming up with an answer that I feel confident about.
-- Karen A. Morrissey
------------------------------
Date: 26 Jul 87 20:37:16 GMT
From: Balu Raman <dartvax!balu.UUCP@seismo.css.gov>
Subject: Problem recognition in database
I am working on recognizing problem instances in Prolog database. The
problems can be typical Graph-color, Linear Programming Problem,
Critical Path Problems etc.etc. Does anybody have references,
pointers, programs to do what I am trying to do.
Thank you.
-- Balu Raman
------------------------------
Date: Tue 28 Jul 87 20:09:49-CDT
From: Hassan Ait-Kaci <AI.HASSAN@MCC.COM>
Subject: Interfile variable scoping
This message is in reaction to Mr. Jeff Klein's question about inter
file variable scoping in C-prolog.
The problem is that Mr. Klein's FILE1 and FILE2 are not just any
files---they are modules. To *link* selected information from and/or
into a module, one must specify which is the imported information,
which is the exported information, and which is the (hidden,
invisible) local information. This is also called abstract data
typing. In Mr.Klein's example, a solution (ad-hoc, since modules are
not supported in C-prolog) would be to proceed exactly thus:
MODULE-1 contains:
export([A,B,C]
,[A,B,C]).
MODULE-2 contains:
export([A,B,C]
,(A = 3, B = C + A)).
sample_predicate:- see('MODULE-1'), read(export(Vars,VECTOR)), seen,
see('MODULE-2'), read(export(Vars,TEST)),seen,
assert(( is_true(VECTOR):-TEST )).
The Vars are imported explicitly by the file containing the reading
clause, and thus locally shared by way of unification. In general, the
problem is not so simple as just plain physical equality, but might
involve quite non-trivial type checking (to ensure that all the wires
are connected as intended). My ad-hoc solution does that for the
variables A, B, and C.
The problem of independent variable naming from reading from separate
files in Prolog is just an instance in the logic programming context
of that posed by the semantics of modules---i.e., of syntactic program
entities sharing scopes of references for some parameters. The problem
presents itself in the lambda calculus when the scope of certain
variables does not obey the rules of lexical scoping. Lexical scoping
freezes the meaning of free parameters in any logical sentence (i.e.,
taking their information content from the static context of the
sentence definition), thus assuming a unique and well-determined
meaning by closing the sentence's parameters. Dynamic scoping lets
them be "context dependent" (i.e., expecting to be passed their
information content from "active contexts" which invoke the sentence),
thus assuming generically many potential meanings. This duality of
scoping is in fact precisely formalized by the semantic duality of
"for-all" (A-quantification) and "there-exists" (E-quantification) in
logic.
In functional programming, programs are first-class object, which
facilitates (in theory) module manipulation. Based on ideas by John
Mitchell (Bell Labs) and Gordon Plotkin (Edinburgh), David MacQueen
(Bell Labs) has proposed an operational semantics of modules for
standard ML. Roughly, A-quantification accounts for universal
polymorphic variables (which are lexical) and E-quantification
accounts for existential polymorphic variables (which are dynamic).
Mads Tofte, a student of Robin Milner's at Edinburgh, is also
developing in his PhD research a calculus of modules for ML based on
"realization maps" among program modules which are functions effecting
the inheritance of contextual information between modules. His ideas
are in curious similarity with my own notion of psi-term structures
(my U.of Penn. PhD thesis) in the context of subtype inheritance.
However, I have not looked at using my ideas on inheritance for
modular information linking (yet).
In (first-order) logic programming, programs are not first-class
objects, making the module problem theoretically more awkward.
Although my knowledge is not deep, I find ideas developed by Dale
Miller (U. of Penn.) and Gopalan Nadathur (formerly of U. of Penn.,
now at Duke) very elegant. They have defined a higher-order
operational logic (the logic programming language Lambda-Prolog,
Nadathur's PhD thesis), with explicit A and E quantification, which
accounts quite nicely for module linking by way of unification.
Finally, it is worth mentioning the original work by Peter Mosses at
University of Aarrhus (sp?) in Denmark whereby he develops a formal
operational semantics (Action Semantics) for modular programming.
-- Hassan Ait-Kaci
MCC, ACA Program
------------------------------
End of PROLOG Digest
********************
∂31-Jul-87 1243 WALDINGER@WARBUCKS.AI.SRI.COM Journal of Automated Reasoning
Received: from WARBUCKS.AI.SRI.COM by SAIL.STANFORD.EDU with TCP; 31 Jul 87 12:43:12 PDT
Return-Path: <@Stripe.SRI.Com,@MC.LCS.MIT.EDU,@OZ.AI.MIT.EDU,@MC.LCS.MIT.EDU:stevens@anl-mcs.ARPA>
Received: from Stripe.SRI.Com by WARBUCKS.AI.SRI.COM via SMTP with TCP;
Thu, 30 Jul 87 20:21:05-PDT
Received: from OZ.AI.MIT.EDU (MC.LCS.MIT.EDU.#Internet) by
STRIPE.SRI.COM with TCP; Thu 30 Jul 87 20:18:47-PDT
Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU with Chaos/SMTP; Thu 30
Jul 87 23:11:29-EDT
Received: from anl-mcs.ARPA (TCP 3200200067) by MC.LCS.MIT.EDU 30 Jul
87 23:05:03 EDT
Received: by anl-mcs.ARPA (4.12/4.9) id AA14310; Thu,
30 Jul 87 22:02:40 cdt
Date: Thu, 30 Jul 87 22:02:40 cdt
From: stevens@anl-mcs.ARPA (Rick L. Stevens)
Message-Id: <8707310302.AA14310@anl-mcs.ARPA>
To: theorem-provers@mc.lcs.mit.edu
Subject: Journal of Automated Reasoning
Cc: stevens@anl-mcs.ARPA
ReSent-date: Fri 31 Jul 87 10:15:10-PDT
ReSent-from: Richard Waldinger <WALDINGER@WARBUCKS.AI.SRI.COM>
ReSent-to: aic-associates, planlunch
Because of the rapidly growing interest in the interconnected
fields of automated reasoning, automated theorem proving, logic
programming, and artificial intelligence, the following information
might be of particular interest.
The Journal of Automated Reasoning, which is very inexpensive
compared to most computer science journals, now includes in each issue
two interesting columns: The Problem Corner, which presents test
problems from the world of puzzles, from mathematics, and from various
applications; and Basic Research Problems, which presents open problems
for research in automated reasoning.
The journal is published quarterly, each issue containing
approximately 110 pages. Beginning next year, each issue will contain
approximately 20% more material, which makes it even more attractive in
view of its cost. Subscription costs are lower for individuals that
are members of the Association of Automated Reasoning. Information in
that regard is also included.
The Journal of Automated Reasoning published its first issue in
February, 1985. It is an interdisciplinary journal that maintains a
balance between theory and application. The spectrum of material
ranges from the presentation of a new inference rule with proofs of its
logical properties to a detailed description of a computer program
designed to solve some problem from industry. The papers published in
this journal are from, among others, the fields of automated theorem
proving, logic programming, expert systems, program synthesis and
validation, artificial intelligence, computational logic, robotics, and
various industrial applications. The papers share the common feature
of focusing on some aspect of automated reasoning.
The journal provides a forum and a means for exchanging
information for those interested in theory, in implementation, and
in specific industrial or commercial applications.
To Subscribe write to Kluwer Academic PO Box 358 Accord
Station Hingham, MA 02018-0358
For outside the U.S. and Canada
Kluwer Academic Publishers Distribution Center PO Box 322 3300 AH
Dordrecht The Netherlands
$97 for institutions, $39 for private non-members of AAR,
$29.50 for members of AAR
AAR, Association for Automated Reasoning
The Association for Automated Reasoning is an organization for
disseminating and exchanging information. It is international in form,
and publishes a newsletter acyclically to announce workshops, discuss
software advances, present problem sets, etc.
To Join send a $5 check to Larry Henschen 780 S. Warrington
Road Des Plaines, IL 60016
-------
∂31-Jul-87 1446 ullman@navajo.stanford.edu Referee(s) wanted
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 31 Jul 87 14:46:18 PDT
Received: by navajo.stanford.edu; Fri, 31 Jul 87 14:41:22 PDT
Date: Fri, 31 Jul 87 14:41:22 PDT
From: Jeff Ullman <ullman@navajo.stanford.edu>
Subject: Referee(s) wanted
To: nail@navajo.stanford.edu
The first volume of my new DB/KB book is getting close to
completion. If anybody would like to be a publisher's referee,
for which a small honorarium is paid (by CSP, not by me),
please send a note to Al Aho (aho@research.att.com).
Incidentally, I added to the nail list all the names I could find
on the XP 7.5i attendence list that were not already there.
If you want to be off the list, or were getting it from some
indirect source already, please send me mail.
---jeff
∂31-Jul-87 1619 @Score.Stanford.EDU:ISMUMICK@Sushi.Stanford.EDU We need a host for New Student Brunch
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 31 Jul 87 16:19:50 PDT
Received: from Sushi.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 31 Jul 87 16:16:41-PDT
Date: Fri 31 Jul 87 16:16:18-PDT
From: Inderpal Singh Mumick <ISMUMICK@Sushi.Stanford.EDU>
Subject: We need a host for New Student Brunch
To: faculty@Score.Stanford.EDU
Office: MJH 460, 723-4096
Residence: Blackwelder 5-C, EV, Stanford, CA 94305. Tel: (415)328-3923
Message-ID: <12322857197.23.ISMUMICK@Sushi.Stanford.EDU>
The orientation committee, as in past years, plans to arrange a
brunch for the new students coming in this fall. This is to welcome
them into the dept, and to give them an opportunity to meet the
faculty and their student advisors.
Traditionally the brunch has been held at a faculty member's home, and I
would like the same to be the case this year too. Tentatively, 11:00 am on
Sun, Sep 27 seems to be a good time.
Kindly let me know if you would be willing to host the brunch, or if
you have any questions. You can expect about 150 guests -- new
students, student advisors, and faculty members. The department funds
the brunch, and the orientation committe will ofcourse help out
extensively.
Inderpal Singh Mumick
-------
-------
∂02-Aug-87 1521 NILSSON@Score.Stanford.EDU conferences
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Aug 87 15:21:45 PDT
Date: Sun 2 Aug 87 15:21:07-PDT
From: Nils Nilsson <NILSSON@Score.Stanford.EDU>
Subject: conferences
To: ac@Score.Stanford.EDU
Message-ID: <12323371439.10.NILSSON@Score.Stanford.EDU>
Following up on Dean Gibbons' note about faculty salary
increases, I would be glad to talk with anyone about salary
or any other matters. I'll be around this coming week,
8/3 to 8/7, away the next week, and then back in town for the
rest of the summer. -Nils
-------
∂03-Aug-87 0120 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #53
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87 01:20:07 PDT
Date: Fri 31 Jul 1987 20:56-PDT
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #53
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Monday, 3 Aug 1987 Volume 5 : Issue 53
Today's Topics:
Implementation - Operator Tests,
Announcement - Logic in Computer Science Call For Papers
----------------------------------------------------------------------
Date: 27 Jul 87 10:07:40 GMT
From: Chris Moss <eagle!icdoc!cdsm@ucbvax.Berkeley.EDU>
Subject: Operator Tests for Prolog
You may have noticed there are subtle differences between the way
different Prolog handle operator definitions. The test file below is
designed to explore some of these on the lines of some of my earlier
tests.
/* Test of Prolog operator implementations
Chris Moss. July 1987. cdsm@doc.ic.ac.uk (or cdsm@icdoc.uucp)
Compile and execute the predicate optest, supplying full description
of system used (with version) as the second parameter. If necessary
delete any clauses which give syntax errors but do NOT change them in
any way (spaces may be crucial). Skip any run-time errors. Send me
the resultant file if it is NOT one of the following or the results
are different. If you get a "parsed differently" message I'd welcome a
modified test which illustrates it as well; also let me know if you've
had to make any changes. You may change the operator declarations if
your system has different conventions. e.g. If your operator
precedence is in the opposite direction then you may add some suitable
constant to ALL the operator priorities.
Thanks to Hamish Taylor for some of these tests. Note that some of the
answers are definitely WRONG. I leave you to decide which!
These are the results I already have (first letter of each message):
Version \ Test 1 2 3 4 5 6 7 8 91011121314151617181920
CProlog 1.5 M P - S - M S P A A A - N N P R D L N
Quintus 2.0 M P - S C M S P A A A - N N P N D L N
MACProlog 2.0 M P - S L L - P A A A - N N P R D L S
Poplog 9.3 D S P P R R S S P S P P N P - R - - -
MuProlog 3.1db M P P P R R P P P P P P P P P R - - -
*/
optest(File,Version) :-
tell(File),
write(['Operator test version 2 using',Version]), nl, nl,
ptest(Summary),
write(Version), write(' '), summary(Summary),
told.
ptest(Summary) :- ptest(1,19,Summary), nl.
ptest(I,N,[]) :- I>N, !.
ptest(I,N,[S|Rest]) :- I=<N,
(otest(I,R), message(I,R,S)
; message(I,'- Failed (to parse) the test',S)),
!, J is I+1, ptest(J,N,Rest).
message(Num,Result,First) :-
write(Num), write(' '), write(Result), nl,
name(Result,[F|_]), name(First,[F]).
summary([]) :- nl.
summary([A|B]) :- write(A), write(' '), summary(B).
:-op(4,fy,r). :-op(6,xfy,r). :-op(2,yf,r).
:-op(4,fy,l). :-op(6,yfx,l). :-op(2,yf,l).
:-op(6,fy,pre). :-op(6,yf,post). :-op(7,yf,bigpost).
:-op(6,fy,both). :-op(6,yf,both).
/* prefix operators and functors */
otest(1,R) :- 'pre'(1,2) = pre (1,2), R ='Dyadic interpretation of pre (1,2)'
; 'pre'(X) = pre (1,2), R = 'Monadic interpretation of pre (1,2)'
; R = 'No, pre (1,2) parsed differently'.
/* Prefix and Postfix ambiguities */
otest(2,R) :- pre(X) = (pre x post),
R = 'Prefix - (pre x post) = pre(post(X))'
; post(X) = (pre x post),
R = 'Suffix - (pre x post) = post(pre(X))'
; R = 'No, (pre x post) parsed differently'.
otest(3,R) :- both(both(a)) = (both both a),
R= 'Prefix - (both both x) = both(both(a))'
; R = 'No, (both both a) parsed differently'.
otest(4,R) :- pre(bigpost) = (pre bigpost),
R = 'Prefix - (pre bigpost) = pre(bigpost)'
; bigpost(pre) = (pre bigpost),
R = 'Suffix - (pre bigpost) = bigpost(pre)'
; R = 'No, (pre bigpost) parsed differently'.
/* ambiguities with infix operators */
otest(5,R) :- 'l'('l'(a),'l'(b)) = (a l l l b),
R = 'Balanced- (a l l l b) = (a l)l(l b)'
; 'l'('l'('l'(a)),b) = (a l l l b),
R = 'Left hand - (a l l l b) = ((a l )l)l b'
; 'l'(a,'l'('l'(b))) = (a l l l b),
R = 'Right hand - (a l l l b) = a l ( l( l b))'
; 'l'('l'(a,l),b) = (a l l l b),
R = 'Constant - (a l l l b) = (a l (l)) l b'
; 'l'(a,'l'(l,b)) = (a l l l b),
R = 'Middle - (a l l l b) = a l((l)l b)'
; R = 'No, (a l l l b) parsed differently'.
otest(6,R) :- 'r'('r'(a),'r'(b)) = (a r r r b),
R = 'Balanced - (a r r r b) = (a r)r(r b)'
; 'r'('r'('r'(a)),b) = (a r r r b),
R = 'Left hand - (a r r r b) = ((a r)r)r b'
; 'r'(a,'r'('r'(b))) = (a r r r b),
R = 'Right hand - (a r r r b) = a r(r(r b))'
; 'r'('r'(a,r),b) = (a r r r b),
R = 'Constant - (a r r r b) = (a r(r))r b'
; 'r'(a,'r'('r',b)) = (a r r r b),
R = 'Middle - (a r r r b) = a r((r)r b)'
; R = 'No, (a r r r b) parsed differently'.
/* Negative integers and the minus sign */
otest(7,R) :- /(X,Y)= -2/3, R = 'Sign, -2/3 parsed (-2)/3'
; -(X) = -2/3, R = 'Prefix, -2/3 parsed -(2/3)'
; R = 'No, -2/3 parsed differently'.
otest(8,R) :- /(X,Y)= -a/b, R = 'Sign, -a/b parsed (-a)/b'
; -(X) = -a/b, R = 'Prefix, -a/b parsed -(a/b)'
; R = 'No, -a/b parsed differently'.
otest(9,R) :- -(-,3) = - - 3, R = 'Atom, - - 3 parsed as (-)-(3)'
; -(-(3)) = - - 3, R = 'Prefix, - - 3 parsed as -(-(3))'
; -(-3) = - - 3, R = 'Sign, - - 3 parsed as -(-3)'
; R = 'No, - - 3 parsed differently'.
otest(10,R) :- -(-,3) = - -3, R = 'Atom, - -3 parsed as (-)-(3)'
; -(-(3)) = - -3, R = 'Prefix, - -3 parsed as -(-(3))'
; -(-3) = - -3, R = 'Sign, - -3 parsed as -(-3)'
; R = 'No, - -3 parsed differently'.
otest(11,R) :- -('-',a) = - - a, R = 'Atom, - - a parsed as (-)-(a)'
; -(-(a)) = - - a, R = 'Prefix, - - a parsed as -(-(a))'
; R = 'No, - - a parsed differently'.
otest(12,R) :- -(a,-b) = a - - b,
R = 'Prefix, a - - b parsed as a-(-b)'
; R = 'No, a - - b parsed differently'.
/* Evaluation of negative and positive integers */
otest(13,R) :- -X = -3, X=3, R = 'Prefix, - is functor of -3'
; R = 'No, - is not functor of -3'.
otest(14,R) :- -X = - 3, X=3, R = 'Prefix, - is functor of - 3'
; R = 'No, - is not functor of - 3'.
otest(15,R) :- +(3) = +3, R = 'Prefix, + is functor of +3'
; R = 'No, + is not functor of +3'.
/* Evaluation of general arithmetic expressions */
otest(16,R) :- oteste(2+3,4,X),!,
(X = 20, R='Remote expressions evaluated'
; R='Different result for remote expressions').
otest(16,R) :- R='No evaluation of remote expressions'.
/* Treatment of | as disjunction */
otest(17,R) :- fail | R='Disjunction can be written as |'.
otest(18,R) :- ';'(a,b) = (A | B), R='Lexical translation of | to ;'
; R = 'No translation of | to ;'.
otest(19,R) :- '|'(a,b) = (A | B), R='Standard treatment of | as operator'
; R = 'No equivalence of (A|B) to prefix form'.
oteste(A, B, C) :- C is A*B.
/* end of tests */
------------------------------
Date: Tue, 28 Jul 87 08:40:54 EDT
From: Yuri_Gurevich%um.cc.umich.edu@forsythe.stanford.edu
Subject: Call
Call For Papers
Third Annual Symposium on
Logic in Computer Science
5-8 July 1988
University of Edinburgh, Edinburgh, Scotland
Concepts and methods from Logic are influential throughout Computer
Science. The Annual IEEE Symposium on Logic in Computer Science (LICS)
aims to attract broad participation of Computer Scientists, whose design
or research activities involve Logic, and Logicians interested in Computer
Science. Suggested (but not exclusive) topics of interest include:
abstract data types, computer theorem proving, concurrency, data base
theory, knowledge representation, finite model theory, lambda and
combinatory calculi, logic programming, modal and temporal logics,
program logic and semantics, software specification, types and categories,
constructive mathematics, verification.
PROGRAM COMMITTEE: M. Dezani, Y. Gurevich (chair), J. Halpern, C.A.R.
Hoare, G. Huet, P. Kanellakis, J.-L.Lassez, J. Mitchell, R. Platek,
G. Plotkin, S. Rosenschein, P. Sistla, J. Tiuryn, M. Wand
PAPER SUBMISSION: Send 14 copies of an extended abstract to the
program chairman:
Yuri Gurevich - LICS (313) 971-2652
Electrical Engineering and Yuri_Gurevich@um.cc.umich.edu
Computer Science Department
University of Michigan
Ann Arbor, Michigan 48109-2122
The package must be airmail postmarked by 27 NOVEMBER 1987 or received by
4 DECEMBER 1987. The abstract should be clearly written and provide
sufficient detail to allow the program committee to assess the merits of
the paper. References and comparisons with related work should be
included where appropriate. The entire extended abstract should not
exceed 10 double-spaced pages in 10 or 12-point font. Late abstracts or
those departing significantly from these guidelines run a high risk of
not being considered. If a copier is not available to the author, a
single copy of the abstract will do.
The authors will be notified of acceptance or rejection by 27 JANUARY
1988. Accepted papers, typed on special forms for inclusion in the
symposium proceedings, will be due 14 MARCH 1988.
The symposium is sponsored by the IEEE Computer Society, Technical
Committee on Mathematical Foundations of Computing , and the University
of Edinburgh, in cooperation with ACM SIGACT, ASL, and EATCS.
ORGANIZING COMMITTEE: J. Barwise, W. Bledsoe, A. Chandra (chair),
E. Dijkstra, E. Engeler, J. Goguen, D. Gries, D. Kozen, Z. Manna,
A. Meyer, R. Parikh, G. Plotkin, D. Scott
GENERAL CHAIRMAN: LOCAL ARRANGEMENTS:
Ashok K. Chandra George Cleland
IBM T. J. Watson Research Center Department of Computer Science
P.O. Box 218 The King's Buildings
Yorktown Heights, NY 10598 University of Edinburgh
(914) 945-1752 Edinburgh EH9 3JZ, SCOTLAND
ashok@ibm.com 011 44 31 667 1081 ext. 2775
glc%lfcs.edinburgh.ac.uk@ucl-cs.arpa
------------------------------
End of PROLOG Digest
********************
∂03-Aug-87 0319 @Sushi.Stanford.EDU:THEORYNT%YKTVMZ.BITNET@forsythe.stanford.edu STOC CALL FOR PAPERS
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87 03:19:46 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Mon 3 Aug 87 03:13:41-PDT
Received: by lindy.stanford.edu; Sun, 2 Aug 87 18:36:52 PDT
Resent-From: THEORYNT%YKTVMZ.BITNET@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Sun, 2 Aug 87 18:36:03 PDT
Date: Fri, 31 Jul 87 10:49:53 PDT
From: Jeff Ullman <ullman@navajo.stanford.edu>
Subject: STOC CALL FOR PAPERS
Message-Id: <C086.THEORYNT@ibm.com>
Resent-Date: 2 Aug 1987 21:33:36-EDT (Sunday)
Reply-To: THEORYNT%YKTVMZ.BITNET@forsythe.stanford.edu
Resent-To: Theory-List.aflb.tn@sushi.stanford.edu;@lindy.stanford.edu
Apparently-To: aflb.tn@SUSHI.STANFORD.EDU
-------------------------------------------------------------------------
CALL FOR PAPERS
1988 ACM SYMPOSIUM ON
THEORY OF COMPUTING
The Twentieth Annual ACM Symposium on Theory of Computing,
sponsored by the ACM Special Interest Group for Automata and
Computability Theory, will be held in Chicago, Ill., May 2-
-4, 1988. Papers presenting original research on theoreti-
cal aspects of Computer Science are sought. Typical, but
not exclusive, topics of interest include the theories of:
Algorithms and data structures
Logics of programs
Computability and complexity
Parallel and distributed computation
Computational geometry
Robotics
Cryptography
Semantics of programming languages
Databases and knowledge bases
VLSI, layout, and logical design
Submission of Abstracts
Authors are requested to send ten copies of a detailed
abstract (not a full paper) by Nov. 1, 1987 to the program
committee chairman:
Jeffrey D. Ullman
Dept. of Computer Science, Bldg. 460
Stanford Univ.
Stanford, CA 94305
The abstract must provide sufficient detail to allow the
program committee to assess the merits of the paper and
should include appropriate references to and comparisons
with extant work. It is recommended that each submission
begin with a succinct statement of the problem, a summary of
the main results, and a brief explanation of the signifi-
cance and relevance to computing of the work, all suitable
for a nonspecialist. Technical development of the work,
directed to the specialist, should follow. A limit of
12,000 bytes (about 10 typed, double-spaced pages) is placed
on submissions.
Abstracts that deviate significantly from these guidelines,
risk rejection without consideration of their merits. Also,
abstracts that are not postmarked by the Nov. 1 deadline
will not be considered.
The program committee consists of Richard Cole, Herbert
Edelsbrunner, Ron Fagin, Greg Frederickson, Nancy Lynch,
Andrew Odlyzko, John Reif, Martin Tompa, Jeff Ullman, and
Andy Yao.
Authors will be notified of acceptance or rejection by Jan.
7, 1988. A copy of each accepted paper is required by Feb.
22, 1988. These copies may be either on special forms
(model pages), which will be sent to the authors, or typeset
as reduced-size (8.5 by 11) model pages. Authors who do not
need the model pages are requested to make note of that fact
in the letter of submittal.
Local Arrangements
Information about local arrangements can be obtained from
the conference chairman:
Janos Simon
Dept. of Computer Science
Univ. of Chicago
Chicago, IL 60637
∂03-Aug-87 0953 ULLMAN@score.stanford.edu [<KERSCH%GMUVAX.BITNET@forsythe.stanford.edu>: Call for Papers: Expert Database Systems Conference]
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87 09:53:53 PDT
Received: from Score.Stanford.EDU by navajo.stanford.edu with TCP; Mon, 3 Aug 87 09:48:10 PDT
Date: Mon 3 Aug 87 09:09:47-PDT
From: Jeffrey D. Ullman <ULLMAN@score.stanford.edu>
Subject: [<KERSCH%GMUVAX.BITNET@forsythe.stanford.edu>: Call for Papers: Expert Database Systems Conference]
To: nail@navajo.stanford.edu
Message-Id: <12323565985.35.ULLMAN@Score.Stanford.EDU>
Return-Path: <KERSCH%GMUVAX.BITNET@forsythe.stanford.edu>
Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 3 Aug 87 03:24:27-PDT
Received: by lindy.stanford.edu; Sun, 2 Aug 87 07:05:47 PDT
Received: by Forsythe.Stanford.EDU; Sun, 2 Aug 87 07:04:57 PDT
Date: Sun, 2 Aug 87 10:04 EST
From: <KERSCH%GMUVAX.BITNET@forsythe.stanford.edu>
Subject: Call for Papers: Expert Database Systems Conference
To: ullman@score.stanford.edu
X-Original-To: ullman@SCORE.STANFORD.EDU,
Ulrich%Tectronix.csnet@csnet-relay.arpa, morgenstern@CSL.SRI.COM, KERSCH
(Please Distribute this Call for Papers to associates)
=====================================================
Call for Papers and Participation
Second International Conference on Expert Database Systems
April 25-27, 1988
The Sheraton Premiere Hotel,
Tysons Corner, Virginia
Sponsored by:
George Mason University
In Cooperation With:
American Association for Artificial Intelligence
Association for Computing Machinery -- SIGART and SIGMOD
IEEE Computer Society -- T. C. on Data Base Engineering
Conference Objectives
The International Conference on Expert Database Systems has
established itself as a leading edge forum that explores the
theoretical and practical issues in making database systems
more intelligent and supportive of Artificial Intelligence
(AI) applications. Expert Database Systems represent the
confluence of R&D activities in Artificial Intelligence,
Database Management, Logic, Information Retrieval, and Fuzzy
Systems Theory. It is precisely this synergism among dis-
ciplines which makes the Conference both stimulating and
unique.
Expert Database Systems will play an ever-increasing role in
scientific, governmental and business applications. The key
is to provide expertise to all facets of database systems,
including:
% providing knowledge-based access to large shared databases
through intelligent user-interfaces and natural-language
question-answering facilities,
% endowing database systems with reasoning, planning, and
justification capabilities,
% defining new classes of knowledge/data models supporting
diverse viewpoints and capable of both temporal and spatial
reasoning,
% creating architectures to support both loose- and tight-
coupling of knowledge base and database systems,
% creating tools and techniques to support the specifica-
tion, manipulation, indexing, adaptation, and evolution of
large knowledge/data bases, and
% integrating AI and DB functional requirements into new
software and hardware environments for the specification,
prototyping, testing and debugging of knowledge/data based
applications.
In order to foster the interchange of ideas from these
diverse fields, the conference will be composed of tutorial
sessions, paper sessions, and panel discussions. Several
invited keynote lectures are planned.
Topics of Interest
The Program Committee invites original theoretical and
application papers (of approximately 5000 words) addressing
(but not limited to) the following areas:
Theory of Knowledge Bases (including knowledge representa-
------ -- --------- -----
tion, knowledge models, knowledge indexing and transforma-
tion, knowledge servers, and formal semantics of
knowledge/data bases).
Object-Oriented Systems (including object-oriented data
------ -------- -------
models, query languages, transaction management, version
control, and modeling applications for enterprises, CAD/CAM,
VLSI, Materials Properties knowledge/data bases, etc.).
Reasoning on Knowledge/Data Bases (including reasoning under
--------- -- --------- ---- -----
uncertainty, sensor fusion, non-monotonic reasoning, analog-
ical reasoning, deductive databases, logic-based query
languages, semantic query optimization and constraint-
directed reasoning).
Knowledge Management (including methodologies for knowledge
--------- ----------
acquisition, the knowledge engineering process, constraint
and rule management, knowledge-based requirements gathering
and specification, and knowledge administration).
Distributed Knowledge/Data Bases (including loosely- and
----------- --------- ---- -----
tightly-coupled architectures, intelligent query decomposi-
tion and processing, federated architectures, distributed
problem-solving, and blackboard techniques for distributed
control and problem solving).
Intelligent Database Interfaces (including expert system --
----------- -------- ----------
database communication, knowledge gateways, knowledgeable
user agents and browsers).
Natural Language Interaction (including question-answering,
------- -------- -----------
extended responses, cooperative behavior, explanation and
justification).
Conference proceedings will be available at the conference.
Please send five copies of papers by October 14, 1987 to
Professor Larry Kerschberg
Dept. of Information Systems and Systems Eng.
George Mason University
4400 University Drive
Fairfax, Virginia 22030
USA
Important Dates
Submission Deadline October 14, 1987
Acceptance Notification: December 15, 1987
Camera-Ready Version: February 1, 1988
Conference Dates: April 25-27, 1988
===========================================================
EDS'88 Organizing Committee
Conference General Chairman
Edgar H. Sibley,
George Mason University
Program Chairman
Larry Kerschberg,
George Mason University
Program Committee
Robert Abarbanel, USA Matthew Morgenstern, USA
Hideo Aiso, Japan John Mylopoulos, Canada
Antonio Albano, Italy Sham Navathe, USA
Stephen J. Andriole, USA Erich Neuhold, FRG
Robert Balzer, USA Setsuo Ohsuga, Japan
Francois Bancilhon, France D. Stott Parker, Jr., USA
Don Batory, USA Alain Pirotte, Belgium
Alex Borgida, USA W. Don Potter, USA
Michael L. Brodie, USA Larry Reeker, USA
Janis Bubenko, Sweden Nick Roussopoulos, USA
Peter Buneman, USA Erik Sandewall, Sweden
Stefano Ceri, Italy Timos Sellis, USA
Umesh Dayal, USA John Miles Smith, USA
Mark Fox, USA Reid Smith, USA
Antonio L. Furtado, Brasil Arne Solvberg, Norway
Herve Gallaire, FRG John Sowa, USA
Barbara Hayes-Roth, USA Jacob Stein, USA
Yannis Ioannidis, USA Michael Stonebraker, USA
Sushil Jajodia, USA Adrian Walker, USA
Matthias Jarke, FRG Andrew B. Whinston, USA
Jonathan King, USA Gio Wiederhold, USA
Roger King, USA Eugene Wong, USA
Robert Meersman, Netherlands Carlo Zaniolo, USA
Tim H. Merrett, Canada
Tutorial and Panel Coordinator
Lucian Russell, USA
Conference Coordinator
Nancy D. Joyner, USA
Exhibits Coordinator
Diane Entner, USA
Publicity Chairman
Jorge Diaz-Herrera, USA
==========================================================
-------
∂03-Aug-87 1052 NILSSON@Score.Stanford.EDU SOE Retreat
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87 10:52:36 PDT
Date: Mon 3 Aug 87 10:51:36-PDT
From: Nils Nilsson <NILSSON@Score.Stanford.EDU>
Subject: SOE Retreat
To: ac@Score.Stanford.EDU
Message-ID: <12323584519.16.NILSSON@Score.Stanford.EDU>
On July 22 the School of Engrg. executive committee (dept. chairs
plus deans) held a retreat to discuss the possible role of SOE
in "manufacturing science." Bob Eustis has written a summary
of the discussion that occurred at the retreat. Anne
Richardson has a copy and will send one to anyone who wants one.
-Nils
-------
∂03-Aug-87 1445 RICHARDSON@Score.Stanford.EDU CRAY
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87 14:39:43 PDT
Date: Mon 3 Aug 87 14:38:22-PDT
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: CRAY
To: ac@Score.Stanford.EDU
Message-ID: <12323625801.21.RICHARDSON@Score.Stanford.EDU>
We have an invitation to Cray's Science and Engineering Symposium which is
to take place September 9-11, 1987 in Minneapolis if anyone is interested
in attending.
-Anne
-------
∂03-Aug-87 1520 @Sushi.Stanford.EDU,@Score.Stanford.EDU:gaifman@navajo.stanford.edu NL=c0-NL
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87 15:20:39 PDT
Received: from Score.Stanford.EDU by Sushi.Stanford.EDU with TCP; Mon 3 Aug 87 15:17:34-PDT
Received: from navajo.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 3 Aug 87 15:05:53-PDT
Received: by navajo.stanford.edu; Mon, 3 Aug 87 15:03:19 PDT
Date: Mon, 3 Aug 87 15:03:19 PDT
From: Haim Gaifman <gaifman@navajo.stanford.edu>
To: PAPA@score.stanford.edu
Cc: aflb.local@score.stanford.edu
In-Reply-To: C. Papadimitriou's message of Tue 14 Jul 87 14:06:00-PDT <12318377029.40.PAPA@Score.Stanford.EDU>
Subject: NL=c0-NL
Can you please mail me that proof? I have an account on navajo and I don't
think I can access your file on score.
Thanks
Haim
∂03-Aug-87 1546 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com PLANLUNCH THIS WEDNESDAY --- Dan Weld
Received: from WARBUCKS.AI.SRI.COM by SAIL.STANFORD.EDU with TCP; 3 Aug 87 15:46:11 PDT
Received: from venice by WARBUCKS.AI.SRI.COM via SMTP with TCP; Mon,
3 Aug 87 15:42:15-PDT
Received: by venice (3.2/4.16) id AA03036 for
planlunch@warbucks.ai.sri.com; Mon, 3 Aug 87 15:42:27 PDT
Date: Mon, 3 Aug 87 15:42:27 PDT
From: Amy Lansky <lansky@venice.ai.sri.com>
Message-Id: <8708032242.AA03036@venice>
To: planlunch@warbucks.ai.sri.com
Subject: PLANLUNCH THIS WEDNESDAY --- Dan Weld
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
Note: Change in day of week and location.
-----------------------------------------------------------------------
COMPARATIVE ANALYSIS
Dan Weld (WELD@XEROX.ARPA)
MIT and Xerox PARC
11:00 AM, WEDNESDAY, August 5
SRI International, Building E, Room EK242
Comparative analysis is the problem of predicting how a system will
react to perturbations in its parameters, and why. For example,
comparative analysis could be asked to explain why the period of an
oscillating spring/block system would increase if the mass of the
block were larger. This talk formalizes the problem of comparative
analysis and presents a technique, differential qualitative (DQ)
analysis, which solves the task.
DQ analysis uses inference rules to deduce qualitative information
about the relative change of system parameters. Multiple perspectives
are used to represent relative change values over intervals of time.
Differential analysis has been implemented, tested on a dozen
examples, and proven sound. Unfortunately, the technique is
incomplete; it always terminates, but does not always return an
answer.
∂03-Aug-87 1616 @Score.Stanford.EDU:LES@SAIL.STANFORD.EDU Welcome Jim Ball
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87 16:16:40 PDT
Received: from SAIL.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Mon 3 Aug 87 16:14:14-PDT
Date: 03 Aug 87 1614 PDT
From: Les Earnest <LES@SAIL.STANFORD.EDU>
Subject: Welcome Jim Ball
To: Staff@SCORE.STANFORD.EDU, Faculty@SCORE.STANFORD.EDU
I am pleased to announce the arrival today of James Ball, who is taking
over as Director of CSD-CF. Jim has been with BBN in Cambridge,
Massachusetts most recently and earlier spent a number of years in this
area with Tymeshare. We are most fortunate in having found such a well-
qualified individual to assume this responsibility.
While Jim is taking over immediately, I would appreciate it if you would
give him an opportunity to learn more about what is going on here before
you start beating up on him.
Les Earnest
∂04-Aug-87 0151 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #54
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Aug 87 01:51:14 PDT
Date: Sun 2 Aug 1987 06:25-PDT
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #54
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Tuesday, 4 Aug 1987 Volume 5 : Issue 54
Today's Topics:
Implementation - Naive Reverse,
Puzzle - Riddle Summary,
Terminology - Direction
----------------------------------------------------------------------
Date: 31 Jul 87 15:24:53 GMT
From: Richard Tobin <mcvax!ukc!its63b!aiva!richard@seismo.css.gov>
Subject: Naive Reverse
A logical inference is a succesful unification with the head if a
clause.
append([], L, L)
requires one logical inference.
append([X|L1], L2, [X|L3])
requires one logical inference plus those required for append(L1, L2, L3).
Writing a(N) for the logical inferences required for append with a
first argument of length N, we have
a(0) = 1
a(N) = 1 + a(N-1)
so ('trivially')
a(N) = N+1.
nairev([], [])
requires one logical inference.
nairev([X|Xs], Zs)
requires one logical inference plus those required for nairev(Xs,Ys),
plus those required for append(Ys, [X], Zs).
Writing n(N) for the logical inferences required for reversing a list of N
elements, we have
n(0) = 1
n(N) = 1 + n(N-1) + a(N-1)
= N+1 + n(N-1) since a(N-1) is N
= N+1 + N + n(N-2) expanding n(N-1)
= N+1 + (N-1)+1 + ... + (2-1)+1 + n(2-2)
= N+1 + N + ... + 2 + 1
= (N+1)(N+2)/2 as is well known (:-)
You could do the last bit by induction if you wanted to be rigorous.
In particular, n(30) = 496.
-- Richard Tobin
Edinburgh University
------------------------------
Date: 31 Jul 87 03:14:55 GMT
From: Lee Naish <uunet!munnari!mulga!lee@seismo.css.gov>
Subject: Prolog riddle summary - (nf)
Without tail recursion optimization there will be N stack frames in
use after the Nth number has been returned. ie O(N).
Its true that in simple implementations there will be N copies of X
around but unless the implementation is extremely brain damaged, all
the copies will be pointing directly to the original variable, not
arranged in a chain of length N. To get the next solution, only the
top stack frame is changed. ie. space is O(N) but time (dereferencing
and manipulating the stack) is O(1) to get the next solution and
therefore O(N) to get N solutions.
Off hand, I cant think of how compilation techniques can improve time
complexity, though there is a factor of a few hardware-years.
-- Lee Naish
------------------------------
Date: 31 Jul 87 07:23:04 GMT
From: Harald Sondergaard <uunet!munnari!harald@seismo.css.gov>
Subject: Terminology
Terminology is certainly an important issue and it is true that we
could need some clarification. The attempt by Chris Moss to start a
discussion is thus praiseworthy. In fact it is guaranteed to succeed
since the draft posted is sufficiently vague to create a heated
debate.
It seems that the attempt is premature. If a group is working on this
under the auspices of BSI, one would expect that it would like to put
off a presentation of its work to a wider audience until the draft was
found reasonably well-balanced, coherent and finished.
A rationale and a statement of purpose would seem to be minimal
requirements for debaters. Who are the addressees of this standard?
Prolog novices? Researchers in programming languages? I would like to
be more constructive, but without a rationale it is a bit difficult.
Following are some more or less specific comments to the draft:
General
Basically, much more precision is needed. As it stands, "Definitions" is
a grossly misleading heading. Also, well established term from logic
programming should be adopted. Lloyd's book by now serves more or less as
a standard, and it would be nice if there were to be no conflicts between
this book and the BSI draft [Lloyd 1984]. In particular, "atom" should be
given the meaning of "atomic formula". (Note that a second edition of
Lloyd's book is due to appear this year, and there are some changes in
terminology as compared to the first edition).
Substitutions
The idea of substitutions being mappings is fine, but note that this is
not in agreement with [Lloyd 1984]. In any case, the fact that substitutions
(apparently) are not assumed to be idempotent causes all kinds of problems.
For instance, is the continual "repeated application" of a substitution
supposed to terminate? Or does {x/f(x)} unify {x,f(x)} ("to unify")? On a
conceptual level, all substitutions generated by unification are idempotent
so why not use the fact to simplify definitions? (Admittedly the set of
idempotent substitutions is not closed under composition, but this never
causes problems for Prolog semantics). It is not stated what is meant by a
minimal substitution ("most general unifier"), and the reader may wonder
what a minimal mapping is. Indeed, if one allows for the lack of idem-
potence, there is no "unique minimal substitution" (under the ordering
we normally assume for substitutions). And in the general case, uniqueness
only holds modulo consistent renaming of variables.
The authors of course know this well, but they should keep in
mind that readers probably do not.
Issues of reference
It is suggested that matters of syntax and of semantics are more carefully
distinguished. It is unclear what it means for a literal (a syntactic
entity) to be "known to be true" ("fact"). Or what it means to "define a
predicate" which is in turn explained as an atom and a natural number
("procedure"). Indeed, the notion of "truth" is never clarified. A good
device for emphasizing the difference between phrases in the language
and what they denote is the term "expression". For instance it would be
more natural to say that nil is a list expression that can denote any
empty list, rather than define lists to be purely syntactic objects.
Miscellaneous
-------------
In the definition of a ground term, "uninstantiated" should be dropped.
It is not clear what "top level" means. Is a "variable substitution"
anything but a substitution ("query")? To "consult" does not sound
natural for reading and storing.
[Lloyd 1984]
Lloyd, John W., Foundations of Logic Programming, Springer-Verlag 1984
-- Harald Sondergaard
University of Copenhagen
------------------------------
End of PROLOG Digest
********************
∂04-Aug-87 1034 JSW Ignorant now running Genera 7.1
To: MJH-LispM@SAIL.STANFORD.EDU
This is going to be a rather long message, so let me summarize the main
points in case you want to ignore the details.
(1) Ignorant (the 3600 in MJH 360) has been upgraded to run Genera 7.1,
the latest version of the Symbolics system. It can still run Release
6.1 if necessary. Ignorant will still serve as the namespace and file
server for the other 3600s in MJH.
(2) Because of various problems with its tape drive and I/O board, the
file system on Ignorant was destroyed and reconstructed. Most files
were saved just before the crash, but several (in particular, everything
in the directory >sys>site) had to be restored from 2-month-old tapes.
Now for the gory details:
In late June, I started to do a full dump of Ignorant's file system.
While writing the second of what would have been six tapes, the tape
drive's rubber head that moves the tape melted, and the drive became
unusable. It was fixed with spare mechanical parts from a Sun's tape
drive about a week ago, and I started a new full dump.
This time, it seemed to have problems responding to the machine after
getting to the end of a tape. To see if it would help solve the problem,
I swapped I/O boards between Ignorant and Mount Saint Coax. This does
seem to have improved the end-of-tape handling, but after a while I
started to see errors on the Fujitsu Eagle that is Ignorant's main disk.
These did not have the appearance of a head crash, since they were
distributed all over the disk instead of concentrated on one surface.
Furthermore, they were mostly in sectors containing data that had recently
been written, e.g., some of the paging area, some directories that I was
in the process of dumping (since their reference date was being updated a
lot), the directory >sys>site, which always gets referenced a lot, and a
few files that I had recently looked at.
So I swapped I/O boards back, but the damage had been done and there was
no apparent way to recover the files that were now inaccessible due to
their directories being clobbered. I was able to finish the full dump for
the rest of the file system, so almost everything was saved. It's not
100% certain, but very likely that the I/O board caused the problem.
On Monday, Symbolics came in to install a new FEP board in Ignorant, which
it needed to run Genera 7.1. After this was done, I reformatted the Eagle
disk and reconstructed the file system from the backup tapes made July 30
and 31. The >sys>site directory, however, was restored from an earlier
full dump and incremental dump tapes the last of which was written on May
31. Changes to >sys>site files between May 31 and July 30 have therefore
disappeared. This includes namespace objects (hosts and users), and
system and translation files that are normally stored there. If you
changed any of these things in the last two months, you should redo the
changes.
Now about Genera 7.1. ("Genera", in case you haven't heard, is the new name
for the basic Symbolics software system.) Release 7 is a major revision,
both internally and in the user interface. There are hundreds of pages
describing the changes, so I won't even begin to mention them, except to
note that compiled code is not portable between the two systems, so it is
necessary to recompile all Lisp files and take care not to load the wrong
versions of files.
Ignorant and Mount Saint Coax have both been upgraded to 7.1. Coax's
hardware upgrade is not complete yet because it lost a power supply last
weekend, and has the bad I/O board mentioned above; but it should soon be
running the new system. The Logic Group's systems are still running 6.1
for now, using some compatibility patches which have been loaded to allow
them to interact with the nameserver running 7.1.
So if you are using a Release 6.1 system, you shouldn't notice much of a
change, though beware of importing .bin files (or, for that matter, .lisp
files) from 7.1 machines.
Not all of the local modifications (printer spoolers, network changes, etc.)
have yet been revised for 7.1, but this should happen in the near future.
∂04-Aug-87 2226 SCHAFFER@Sushi.Stanford.EDU Next AFLB
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Aug 87 22:26:39 PDT
Date: Tue 4 Aug 87 22:23:41-PDT
From: Alejandro Schaffer <SCHAFFER@Sushi.Stanford.EDU>
Subject: Next AFLB
To: aflb.all@Sushi.Stanford.EDU
Message-ID: <12323972653.20.SCHAFFER@Sushi.Stanford.EDU>
6-August-1987: Anil Gangolli (Stanford)
Generating Random Combinatorial Objects with Random Walks
Suppose we have a set S of objects from which we wish to choose a
member approximately uniformly at random, that is, each with
probability 1/|S|, or nearly so. Even given a source of unbiased
independent random bits, it may not be obvious how to do this. We may
not even know precisely what |S| is. Recent results by Broder on
approximating the permanent, and work in progress by Diaconis and
Gangolli on problems related to chi-squared testing use "random walks"
on relevant sets S to choose elements uniformly or nearly uniformly at
random.
We'll discuss how this approach works, some of the questions which arise
naturally when one takes it, and some techniques one can use for answering
these questions.
Only a basic background in discrete probability, and some linear algebra
will be assumed.
***** Time and place: August 6, 12:30pm in MJ352 (Bldg. 460) *****
-------
con-Aug-87 1037 BSCOTT@Score.Stanford.EDU Audit--Expenditure Statements
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 5 Aug 87 10:37:08 PDT
Date: Wed 5 Aug 87 10:36:17-PDT
From: Betty Scott <BSCOTT@Score.Stanford.EDU>
Subject: Audit--Expenditure Statements
To: AC@Score.Stanford.EDU
cc: AV.CJB@Forsythe.Stanford.EDU, BScott@Score.Stanford.EDU
Message-ID: <12324106018.16.BSCOTT@Score.Stanford.EDU>
As most of you know, we are required to keep SIGNED copies of your monthly
expenditure statements. Some of you (but not all) do not return these
statements on a timely basis.
Our records and files are being audited at the present time, and it is obvious
that some of the expenditure statements have not been signed and returned. We
have not been able to accurately track this procedure due to the shortage of
staff and the lack of time.
In order to avoid the auditor's direct request to you, it is absolutely
necessary that any and all expenditure statements in your possession at the
present time be signed and returned to Sharon immediately.
Thanks for your immediate attention.
Betty
-------
∂05-Aug-87 1213 @Sushi.Stanford.EDU:THEORYNT%YKTVMZ.BITNET@forsythe.stanford.edu Structures 88 Call for Papers
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 5 Aug 87 12:13:02 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Wed 5 Aug 87 12:05:02-PDT
Received: by lindy.stanford.edu; Wed, 5 Aug 87 12:05:16 PDT
Resent-From: THEORYNT%YKTVMZ.BITNET@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Wed, 5 Aug 87 12:01:13 PDT
Date: Wed, 5 Aug 87 11:16:05 EDT
From: selman%corwin.ccs.northeastern.edu@relay.cs.net
Subject: Structures 88 Call for Papers
Message-Id: <C087.THEORYNT@ibm.com>
Resent-Date: 5 Aug 1987 14:11:30-EDT (Wednesday)
Resent-Sender: THEORYNT%YKTVMZ.BITNET@forsythe.stanford.edu
Resent-To: aflb.tn@sushi.stanford.edu
Apparently-To: aflb.tn@SUSHI.STANFORD.EDU
----------------------------------------------------------------------------
Call for Papers
Structure in Complexity Theory
Third Annual Conference
14-17 June 1988
Georgetown University, Washington, DC
The Structure in Complexity Theory Conference focuses on structural proper-
ties of complexity classes and complexity-bounded reducibilities. Topics of
interest include, but are not limited to, the following issues in complexity
theory:
Structure of complexity classes Theory of relativizations
Relations between complexity classes Independence results
Properties of complete sets Kolmogorov complexity
Resource-bounded reducibilities Cryptographic complexity
Applications of recursion theory Random and interactive proof systems
Applications of finite model theory
Original research papers and technical expository talks are sought. Au-
thors can anticipate 40 minutes for presenting research papers and 60 minutes
for expository talks. Send 7 copies of an extended abstract or full draft pa-
per by November 20, 1987 to
Juris Hartmanis
Computer Science Department
Cornell University
Upson Hall
Ithaca, NY 14853, U.S.A.
Authors of accepted papers will be expected to present their work at the
Conference. Authors will be notified of acceptance or rejection by January
29, 1988. Final papers typed on special forms for inclusion in the Conference
Proceedings are due March 18, 1988.
The Program Committee consists of Ronald Book, Juris Hartmanis, Richard
Ladner, Tim Long, James Royer, Uwe Schoening, and Klaus Wagner. Some members
of the program committee will present research talks or technical expository
talks providing perspective on their current research programs.
The conference is sponsored by the IEEE Computer Society Technical Commit-
tee for Mathematical Foundations of Computing and Georgetown University, in
cooperation with ACM SIGACT.
Conference Chairman Program Chairman Local Arrangements
Alan L. Selman Juris Hartmanis John C. Cherniavsky
College of Computer Science Computer Science Dept. Computer Science Dept.
Northeastern University Cornell University Georgetown University
360 Huntington Ave. Upson Hall Washington, D.C. 20057
Boston, MA 02115 Ithaca, NY 14853
∂05-Aug-87 1936 @Score.Stanford.EDU,@RELAY.CS.NET:golub@research.att.com Re: Audit--Expenditure Statements
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 5 Aug 87 19:36:06 PDT
Received: from RELAY.CS.NET by SCORE.STANFORD.EDU with TCP; Wed 5 Aug 87 19:34:58-PDT
Received: from relay2.cs.net by RELAY.CS.NET id ab27328; 5 Aug 87 22:32 EDT
Received: from btl by csnet-relay.csnet id av22693; 5 Aug 87 22:22 EDT
To: AC%score.stanford.edu@RELAY.CS.NET
From: golub%research.att.com@RELAY.CS.NET
Date: Wed 5 Aug EDT 1987 19:05
Original-To: AC@score.stanford.edu, research!csnet!score.stanford.edu!BSCOTT
Subject: Re: Audit--Expenditure Statements
Cc: AV.CJB@forsythe.stanford.edu, BScott@score.stanford.edu
It would be helpful if we got our statements in a more timely manner.
Gene
∂06-Aug-87 0300 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #56
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Aug 87 02:59:54 PDT
Date: Wed 5 Aug 1987 12:43-PDT
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #56
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Thursday, 6 Aug 1987 Volume 5 : Issue 56
Today's Topics:
LP Library - AI Expert Benchmarks
----------------------------------------------------------------------
Date: Sat, 1 Aug 87 18:40:17 PDT
From: Fernando Pereira <pereira@stinson.ai.sri.com>
Subject: AI Expert Prolog benchmarks
I've received several requests for the benchmarks that were used in
the June issue of AI Expert. The purpose of these benchmarks is to try
to identify strengths and weaknesses in the basic engine of a Prolog
system. In particular, I try to separate costs normaly conflated in
other benchmark suites, such as procedure call cost, term matching and
term construction costs and the costs of tail calls vs. nontail calls.
I'm sure the benchmarks could be improved, but I don't have time to
work on them right now. Also, I must say that I have relatively little
faith on small benchmark programs. I find that performance (both time
and space) on substantial programs, reliability, adherence to de facto
standards and ease of use are far more important in practice. I've
tried several Prolog systems that performed very well on small
benchmarks (including mine), but that failed badly on one or more of
these criteria.
Some of the benchmarks are inspired on a benchmark suite developed at
ICOT for their SIM project, and other benchmark choices were
influenced by discussions with ICOT researchers on the relative
performance of SIM-I vs. Prolog-20.
-- Fernando Pereira
File #1, driver.pl:
% File : driver.pl
% Author : Richard O'Keefe based on earlier versions due to
% Paul Wilk, Fernando Pereira, David Warren et al.
% Updated: 29 December 1986
% Defines: from/3 and get_cpu_time/1.
% Version: Dec-10 Prolog & Quintus Prolog.
:- public
from/3,
get_cpu_time/1.
:- mode
from(+, +, -),
get_cpu_time(-).
% from(LowerBound, UpperBound, I)
% binds I to successive integers in the range LowerBound..UpperBound.
% It is designed solely for use in this application; for a general
% way of doing this use the standard library predicate between/3, or
% perhaps repeat/1.
from(I, I, I) :- !.
from(L, U, I) :- M is (L+U) >> 1, from(L, M, I).
from(L, U, I) :- M is (L+U) >> 1 + 1, from(M, U, I).
% get_cpu_time(T)
% unifies T with the run time since start-up in milliseconds.
% (We can't use the second element of the list, as some of the
% tests will call statistics/2 and reset it.)
get_cpu_time(T) :-
statistics(runtime, [T,_]).
% report(N, T0, T1, T2)
% takes the three times yielded by get_cpu_time and the number
% of iterations and prints the total, overhead, and average.
report(N, T0, T1, T2) :-
TestTime is T1-T0,
OverHead is T2-T1,
Average is (TestTime-OverHead)/N,
write((TestTime-OverHead)/N=Average),
write(' milli-seconds/iteration'), nl.
% bench_mark(Name)
% is the new top level. It calls bench_mark/4 to find out
% how many Iterations of the Action and its Control to perform.
% To get the old effect, do something like
% bench_mark(nrev, 50, nrev(L), dummy(L)) :- data(L).
bench_mark(Name) :-
bench_mark(Name, Iterations, Action, Control),
get_cpu_time(T0),
( repeat(Iterations), call(Action), fail
; get_cpu_time(T1)
),
( repeat(Iterations), call(Control), fail
; get_cpu_time(T2)
),
write(Name), write(' took '),
report(Iterations, T0, T1, T2).
% repeat(N)
% succeeds precisely N times.
repeat(N) :-
N > 0,
from(1, N).
from(I, I) :- !.
from(L, U) :- M is (L+U)>>1, from(L, M).
from(L, U) :- M is (L+U)>>1+1, from(M, U).
File #2, benches.pl
% File : benches.pl
% Author : Fernando Pereira
% Updated: 29 December 1986
% Defines: benches/0, bench_mark/1
% Purpose:
% Here are all the benchmarks. Some are based on the ICOT benchmark set
% (version of January 24, 1985), others are different. All the benchmarks
% attempt to measure just one thing, eg. determinate procedure call, list
% construction, list destruction.
% To run the whole set, call 'benches'.
% Do all the benchmarks
:- public benches/0, bench_mark/1.
benches :-
bench_mark(Name, _, _, _),
bench_mark(Name),
fail.
benches.
% Trivial predicates for use in controls.
:- public dummy/0, dummy/1, dummy/2, dummy/3.
dummy.
dummy(_).
dummy(_, _).
dummy(_, _, _).
% The actual benchamarks
% 1. 100 determinate tail calls
bench_mark(tail_call_atom_atom, 2000, p1(a), dummy(a)).
:- public p1/1.
p1(a) :- p2(a).
p2(a) :- p3(a).
p3(a) :- p4(a).
p4(a) :- p5(a).
p5(a) :- p6(a).
p6(a) :- p7(a).
p7(a) :- p8(a).
p8(a) :- p9(a).
p9(a) :- p10(a).
p10(a) :- p11(a).
p11(a) :- p12(a).
p12(a) :- p13(a).
p13(a) :- p14(a).
p14(a) :- p15(a).
p15(a) :- p16(a).
p16(a) :- p17(a).
p17(a) :- p18(a).
p18(a) :- p19(a).
p19(a) :- p20(a).
p20(a) :- p21(a).
p21(a) :- p22(a).
p22(a) :- p23(a).
p23(a) :- p24(a).
p24(a) :- p25(a).
p25(a) :- p26(a).
p26(a) :- p27(a).
p27(a) :- p28(a).
p28(a) :- p29(a).
p29(a) :- p30(a).
p30(a) :- p31(a).
p31(a) :- p32(a).
p32(a) :- p33(a).
p33(a) :- p34(a).
p34(a) :- p35(a).
p35(a) :- p36(a).
p36(a) :- p37(a).
p37(a) :- p38(a).
p38(a) :- p39(a).
p39(a) :- p40(a).
p40(a) :- p41(a).
p41(a) :- p42(a).
p42(a) :- p43(a).
p43(a) :- p44(a).
p44(a) :- p45(a).
p45(a) :- p46(a).
p46(a) :- p47(a).
p47(a) :- p48(a).
p48(a) :- p49(a).
p49(a) :- p50(a).
p50(a) :- p51(a).
p51(a) :- p52(a).
p52(a) :- p53(a).
p53(a) :- p54(a).
p54(a) :- p55(a).
p55(a) :- p56(a).
p56(a) :- p57(a).
p57(a) :- p58(a).
p58(a) :- p59(a).
p59(a) :- p60(a).
p60(a) :- p61(a).
p61(a) :- p62(a).
p62(a) :- p63(a).
p63(a) :- p64(a).
p64(a) :- p65(a).
p65(a) :- p66(a).
p66(a) :- p67(a).
p67(a) :- p68(a).
p68(a) :- p69(a).
p69(a) :- p70(a).
p70(a) :- p71(a).
p71(a) :- p72(a).
p72(a) :- p73(a).
p73(a) :- p74(a).
p74(a) :- p75(a).
p75(a) :- p76(a).
p76(a) :- p77(a).
p77(a) :- p78(a).
p78(a) :- p79(a).
p79(a) :- p80(a).
p80(a) :- p81(a).
p81(a) :- p82(a).
p82(a) :- p83(a).
p83(a) :- p84(a).
p84(a) :- p85(a).
p85(a) :- p86(a).
p86(a) :- p87(a).
p87(a) :- p88(a).
p88(a) :- p89(a).
p89(a) :- p90(a).
p90(a) :- p91(a).
p91(a) :- p92(a).
p92(a) :- p93(a).
p93(a) :- p94(a).
p94(a) :- p95(a).
p95(a) :- p96(a).
p96(a) :- p97(a).
p97(a) :- p98(a).
p98(a) :- p99(a).
p99(a) :- p100(a).
p100(a).
% 2. 63 determinate nontail calls, 64 determinate tail calls.
bench_mark(binary_call_atom_atom, 2000, q1(a), dummy(a)).
:- public q1/1.
q1(a) :- q2(a), q3(a).
q2(a) :- q4(a), q5(a).
q3(a) :- q6(a), q7(a).
q4(a) :- q8(a), q9(a).
q5(a) :- q10(a), q11(a).
q6(a) :- q12(a), q13(a).
q7(a) :- q14(a), q15(a).
q8(a) :- q16(a), q17(a).
q9(a) :- q18(a), q19(a).
q10(a) :- q20(a), q21(a).
q11(a) :- q22(a), q23(a).
q12(a) :- q24(a), q25(a).
q13(a) :- q26(a), q27(a).
q14(a) :- q28(a), q29(a).
q15(a) :- q30(a), q31(a).
q16(a) :- q32(a), q33(a).
q17(a) :- q34(a), q35(a).
q18(a) :- q36(a), q37(a).
q19(a) :- q38(a), q39(a).
q20(a) :- q40(a), q41(a).
q21(a) :- q42(a), q43(a).
q22(a) :- q44(a), q45(a).
q23(a) :- q46(a), q47(a).
q24(a) :- q48(a), q49(a).
q25(a) :- q50(a), q51(a).
q26(a) :- q52(a), q53(a).
q27(a) :- q54(a), q55(a).
q28(a) :- q56(a), q57(a).
q29(a) :- q58(a), q59(a).
q30(a) :- q60(a), q61(a).
q31(a) :- q62(a), q63(a).
q32(a) :- q64(a), q65(a).
q33(a) :- q66(a), q67(a).
q34(a) :- q68(a), q69(a).
q35(a) :- q70(a), q71(a).
q36(a) :- q72(a), q73(a).
q37(a) :- q74(a), q75(a).
q38(a) :- q76(a), q77(a).
q39(a) :- q78(a), q79(a).
q40(a) :- q80(a), q81(a).
q41(a) :- q82(a), q83(a).
q42(a) :- q84(a), q85(a).
q43(a) :- q86(a), q87(a).
q44(a) :- q88(a), q89(a).
q45(a) :- q90(a), q91(a).
q46(a) :- q92(a), q93(a).
q47(a) :- q94(a), q95(a).
q48(a) :- q96(a), q97(a).
q49(a) :- q98(a), q99(a).
q50(a) :- q100(a), q101(a).
q51(a) :- q102(a), q103(a).
q52(a) :- q104(a), q105(a).
q53(a) :- q106(a), q107(a).
q54(a) :- q108(a), q109(a).
q55(a) :- q110(a), q111(a).
q56(a) :- q112(a), q113(a).
q57(a) :- q114(a), q115(a).
q58(a) :- q116(a), q117(a).
q59(a) :- q118(a), q119(a).
q60(a) :- q120(a), q121(a).
q61(a) :- q122(a), q123(a).
q62(a) :- q124(a), q125(a).
q63(a) :- q126(a), q127(a).
q64(a).
q65(a).
q66(a).
q67(a).
q68(a).
q69(a).
q70(a).
q71(a).
q72(a).
q73(a).
q74(a).
q75(a).
q76(a).
q77(a).
q78(a).
q79(a).
q80(a).
q81(a).
q82(a).
q83(a).
q84(a).
q85(a).
q86(a).
q87(a).
q88(a).
q89(a).
q90(a).
q91(a).
q92(a).
q93(a).
q94(a).
q95(a).
q96(a).
q97(a).
q98(a).
q99(a).
q100(a).
q101(a).
q102(a).
q103(a).
q104(a).
q105(a).
q106(a).
q107(a).
q108(a).
q109(a).
q110(a).
q111(a).
q112(a).
q113(a).
q114(a).
q115(a).
q116(a).
q117(a).
q118(a).
q119(a).
q120(a).
q121(a).
q122(a).
q123(a).
q124(a).
q125(a).
q126(a).
q127(a).
% 3. Construct one 100 element list, nonrecursively.
bench_mark(cons_list, 2000, r1(L), dummy(L)).
:- public r1/1.
% 4. Walk down a 100 element list, nonrecursively
bench_mark(walk_list, 2000, r1(L), dummy(L)) :- r1(L).
% 5. Walk down a 100 element list, recursively
bench_mark(walk_list_rec, 2000, wlr(L), dummy(L)) :- r1(L).
:- public wlr/1.
% 6. Walk down N 100 copies of the same 100 element list, recursively.
bench_mark(args(N), 2000, args(N, L), dummy(N, L)) :- args(N), r1(L).
:- public args/2.
args(1). args(2). args(4). args(8). args(16).
args(1, L) :- wlr(L).
args(2, L) :- wlr(L, L).
args(4, L) :- wlr(L, L, L, L).
args(8, L) :- wlr(L, L, L, L, L, L, L, L).
args(16, L) :- wlr(L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L).
wlr([]).
wlr([_|L]) :- wlr(L).
wlr([], []).
wlr([_|L1], [_|L2]) :- wlr(L1, L2).
wlr([], [], [], []).
wlr([_|L1], [_|L2], [_|L3], [_|L4]) :- wlr(L1, L2, L3, L4).
wlr([], [], [], [], [], [], [], []).
wlr([_|L1], [_|L2], [_|L3], [_|L4], [_|L5], [_|L6], [_|L7], [_|L8]) :-
wlr(L1, L2, L3, L4, L5, L6, L7, L8).
wlr([], [], [], [], [], [], [], [], [], [], [], [], [], [], [], []).
wlr([_|L1], [_|L2], [_|L3], [_|L4], [_|L5], [_|L6], [_|L7], [_|L8],
[_|L9], [_|L10], [_|L11], [_|L12], [_|L13], [_|L14], [_|L15], [_|L16]) :-
wlr(L1, L2, L3, L4, L5, L6, L7, L8, L9, L10, L11, L12, L13, L14, L15, L16).
% Nonrecursive list cruncher
r1([1|R]) :- r2(R).
r2([2|R]) :- r3(R).
r3([3|R]) :- r4(R).
r4([4|R]) :- r5(R).
r5([5|R]) :- r6(R).
r6([6|R]) :- r7(R).
r7([7|R]) :- r8(R).
r8([8|R]) :- r9(R).
r9([9|R]) :- r10(R).
r10([10|R]) :- r11(R).
r11([11|R]) :- r12(R).
r12([12|R]) :- r13(R).
r13([13|R]) :- r14(R).
r14([14|R]) :- r15(R).
r15([15|R]) :- r16(R).
r16([16|R]) :- r17(R).
r17([17|R]) :- r18(R).
r18([18|R]) :- r19(R).
r19([19|R]) :- r20(R).
r20([20|R]) :- r21(R).
r21([21|R]) :- r22(R).
r22([22|R]) :- r23(R).
r23([23|R]) :- r24(R).
r24([24|R]) :- r25(R).
r25([25|R]) :- r26(R).
r26([26|R]) :- r27(R).
r27([27|R]) :- r28(R).
r28([28|R]) :- r29(R).
r29([29|R]) :- r30(R).
r30([30|R]) :- r31(R).
r31([31|R]) :- r32(R).
r32([32|R]) :- r33(R).
r33([33|R]) :- r34(R).
r34([34|R]) :- r35(R).
r35([35|R]) :- r36(R).
r36([36|R]) :- r37(R).
r37([37|R]) :- r38(R).
r38([38|R]) :- r39(R).
r39([39|R]) :- r40(R).
r40([40|R]) :- r41(R).
r41([41|R]) :- r42(R).
r42([42|R]) :- r43(R).
r43([43|R]) :- r44(R).
r44([44|R]) :- r45(R).
r45([45|R]) :- r46(R).
r46([46|R]) :- r47(R).
r47([47|R]) :- r48(R).
r48([48|R]) :- r49(R).
r49([49|R]) :- r50(R).
r50([50|R]) :- r51(R).
r51([51|R]) :- r52(R).
r52([52|R]) :- r53(R).
r53([53|R]) :- r54(R).
r54([54|R]) :- r55(R).
r55([55|R]) :- r56(R).
r56([56|R]) :- r57(R).
r57([57|R]) :- r58(R).
r58([58|R]) :- r59(R).
r59([59|R]) :- r60(R).
r60([60|R]) :- r61(R).
r61([61|R]) :- r62(R).
r62([62|R]) :- r63(R).
r63([63|R]) :- r64(R).
r64([64|R]) :- r65(R).
r65([65|R]) :- r66(R).
r66([66|R]) :- r67(R).
r67([67|R]) :- r68(R).
r68([68|R]) :- r69(R).
r69([69|R]) :- r70(R).
r70([70|R]) :- r71(R).
r71([71|R]) :- r72(R).
r72([72|R]) :- r73(R).
r73([73|R]) :- r74(R).
r74([74|R]) :- r75(R).
r75([75|R]) :- r76(R).
r76([76|R]) :- r77(R).
r77([77|R]) :- r78(R).
r78([78|R]) :- r79(R).
r79([79|R]) :- r80(R).
r80([80|R]) :- r81(R).
r81([81|R]) :- r82(R).
r82([82|R]) :- r83(R).
r83([83|R]) :- r84(R).
r84([84|R]) :- r85(R).
r85([85|R]) :- r86(R).
r86([86|R]) :- r87(R).
r87([87|R]) :- r88(R).
r88([88|R]) :- r89(R).
r89([89|R]) :- r90(R).
r90([90|R]) :- r91(R).
r91([91|R]) :- r92(R).
r92([92|R]) :- r93(R).
r93([93|R]) :- r94(R).
r94([94|R]) :- r95(R).
r95([95|R]) :- r96(R).
r96([96|R]) :- r97(R).
r97([97|R]) :- r98(R).
r98([98|R]) :- r99(R).
r99([99|R]) :- r100(R).
r100([100|R]) :- r101(R).
r101([]).
% 7. Construct a term with 100 nodes, nonrecursively
bench_mark(cons_term, 2000, s1(T), dummy(T)).
:- public s1/1.
% 8. Walk down a term with 100 nodes, nonrecursively.
bench_mark(walk_term, 2000, s1(T), dummy(T)) :- s1(T).
% 9. Walk down a term with 100 nodes, recursively.
bench_mark(walk_term_rec, 2000, wtr(T), dummy(T)) :- s1(T).
:- public wtr/1.
wtr(nil).
wtr(f(_,R)) :- wtr(R).
% Nonrecursive term cruncher
s1(f(1, R)) :- s2(R).
s2(f(2, R)) :- s3(R).
s3(f(3, R)) :- s4(R).
s4(f(4, R)) :- s5(R).
s5(f(5, R)) :- s6(R).
s6(f(6, R)) :- s7(R).
s7(f(7, R)) :- s8(R).
s8(f(8, R)) :- s9(R).
s9(f(9, R)) :- s10(R).
s10(f(10, R)) :- s11(R).
s11(f(11, R)) :- s12(R).
s12(f(12, R)) :- s13(R).
s13(f(13, R)) :- s14(R).
s14(f(14, R)) :- s15(R).
s15(f(15, R)) :- s16(R).
s16(f(16, R)) :- s17(R).
s17(f(17, R)) :- s18(R).
s18(f(18, R)) :- s19(R).
s19(f(19, R)) :- s20(R).
s20(f(20, R)) :- s21(R).
s21(f(21, R)) :- s22(R).
s22(f(22, R)) :- s23(R).
s23(f(23, R)) :- s24(R).
s24(f(24, R)) :- s25(R).
s25(f(25, R)) :- s26(R).
s26(f(26, R)) :- s27(R).
s27(f(27, R)) :- s28(R).
s28(f(28, R)) :- s29(R).
s29(f(29, R)) :- s30(R).
s30(f(30, R)) :- s31(R).
s31(f(31, R)) :- s32(R).
s32(f(32, R)) :- s33(R).
s33(f(33, R)) :- s34(R).
s34(f(34, R)) :- s35(R).
s35(f(35, R)) :- s36(R).
s36(f(36, R)) :- s37(R).
s37(f(37, R)) :- s38(R).
s38(f(38, R)) :- s39(R).
s39(f(39, R)) :- s40(R).
s40(f(40, R)) :- s41(R).
s41(f(41, R)) :- s42(R).
s42(f(42, R)) :- s43(R).
s43(f(43, R)) :- s44(R).
s44(f(44, R)) :- s45(R).
s45(f(45, R)) :- s46(R).
s46(f(46, R)) :- s47(R).
s47(f(47, R)) :- s48(R).
s48(f(48, R)) :- s49(R).
s49(f(49, R)) :- s50(R).
s50(f(50, R)) :- s51(R).
s51(f(51, R)) :- s52(R).
s52(f(52, R)) :- s53(R).
s53(f(53, R)) :- s54(R).
s54(f(54, R)) :- s55(R).
s55(f(55, R)) :- s56(R).
s56(f(56, R)) :- s57(R).
s57(f(57, R)) :- s58(R).
s58(f(58, R)) :- s59(R).
s59(f(59, R)) :- s60(R).
s60(f(60, R)) :- s61(R).
s61(f(61, R)) :- s62(R).
s62(f(62, R)) :- s63(R).
s63(f(63, R)) :- s64(R).
s64(f(64, R)) :- s65(R).
s65(f(65, R)) :- s66(R).
s66(f(66, R)) :- s67(R).
s67(f(67, R)) :- s68(R).
s68(f(68, R)) :- s69(R).
s69(f(69, R)) :- s70(R).
s70(f(70, R)) :- s71(R).
s71(f(71, R)) :- s72(R).
s72(f(72, R)) :- s73(R).
s73(f(73, R)) :- s74(R).
s74(f(74, R)) :- s75(R).
s75(f(75, R)) :- s76(R).
s76(f(76, R)) :- s77(R).
s77(f(77, R)) :- s78(R).
s78(f(78, R)) :- s79(R).
s79(f(79, R)) :- s80(R).
s80(f(80, R)) :- s81(R).
s81(f(81, R)) :- s82(R).
s82(f(82, R)) :- s83(R).
s83(f(83, R)) :- s84(R).
s84(f(84, R)) :- s85(R).
s85(f(85, R)) :- s86(R).
s86(f(86, R)) :- s87(R).
s87(f(87, R)) :- s88(R).
s88(f(88, R)) :- s89(R).
s89(f(89, R)) :- s90(R).
s90(f(90, R)) :- s91(R).
s91(f(91, R)) :- s92(R).
s92(f(92, R)) :- s93(R).
s93(f(93, R)) :- s94(R).
s94(f(94, R)) :- s95(R).
s95(f(95, R)) :- s96(R).
s96(f(96, R)) :- s97(R).
s97(f(97, R)) :- s98(R).
s98(f(98, R)) :- s99(R).
s99(f(99, R)) :- s100(R).
s100(f(100, R)) :- s101(R).
s101(nil).
% 10. 99 shallow failures; assumes no indexing on 2nd argument
bench_mark(shallow_backtracking, 2000, shallow, dummy).
:- public shallow/0.
% 11. 99 deep failures; assumes no indexing on 2nd argument
bench_mark(deep_backtracking, 2000, deep, dummy).
:- public deep/0.
shallow :- b(_X, 100).
deep :- b(_X, Y), Y = 100.
b(_X, 1).
b(_X, 2).
b(_X, 3).
b(_X, 4).
b(_X, 5).
b(_X, 6).
b(_X, 7).
b(_X, 8).
b(_X, 9).
b(_X, 10).
b(_X, 11).
b(_X, 12).
b(_X, 13).
b(_X, 14).
b(_X, 15).
b(_X, 16).
b(_X, 17).
b(_X, 18).
b(_X, 19).
b(_X, 20).
b(_X, 21).
b(_X, 22).
b(_X, 23).
b(_X, 24).
b(_X, 25).
b(_X, 26).
b(_X, 27).
b(_X, 28).
b(_X, 29).
b(_X, 30).
b(_X, 31).
b(_X, 32).
b(_X, 33).
b(_X, 34).
b(_X, 35).
b(_X, 36).
b(_X, 37).
b(_X, 38).
b(_X, 39).
b(_X, 40).
b(_X, 41).
b(_X, 42).
b(_X, 43).
b(_X, 44).
b(_X, 45).
b(_X, 46).
b(_X, 47).
b(_X, 48).
b(_X, 49).
b(_X, 50).
b(_X, 51).
b(_X, 52).
b(_X, 53).
b(_X, 54).
b(_X, 55).
b(_X, 56).
b(_X, 57).
b(_X, 58).
b(_X, 59).
b(_X, 60).
b(_X, 61).
b(_X, 62).
b(_X, 63).
b(_X, 64).
b(_X, 65).
b(_X, 66).
b(_X, 67).
b(_X, 68).
b(_X, 69).
b(_X, 70).
b(_X, 71).
b(_X, 72).
b(_X, 73).
b(_X, 74).
b(_X, 75).
b(_X, 76).
b(_X, 77).
b(_X, 78).
b(_X, 79).
b(_X, 80).
b(_X, 81).
b(_X, 82).
b(_X, 83).
b(_X, 84).
b(_X, 85).
b(_X, 86).
b(_X, 87).
b(_X, 88).
b(_X, 89).
b(_X, 90).
b(_X, 91).
b(_X, 92).
b(_X, 93).
b(_X, 94).
b(_X, 95).
b(_X, 96).
b(_X, 97).
b(_X, 98).
b(_X, 99).
b(_X, 100).
% 12. Push 100 choice points
% Assumes no super-clever (multipredicate) optimizer
bench_mark(choice_point, 2000, choice, dummy).
:- public choice/0.
choice :- c1(a), !.
c1(a) :- c2(a).
c1(a).
c2(a) :- c3(a).
c2(a).
c3(a) :- c4(a).
c3(a).
c4(a) :- c5(a).
c4(a).
c5(a) :- c6(a).
c5(a).
c6(a) :- c7(a).
c6(a).
c7(a) :- c8(a).
c7(a).
c8(a) :- c9(a).
c8(a).
c9(a) :- c10(a).
c9(a).
c10(a) :- c11(a).
c10(a).
c11(a) :- c12(a).
c11(a).
c12(a) :- c13(a).
c12(a).
c13(a) :- c14(a).
c13(a).
c14(a) :- c15(a).
c14(a).
c15(a) :- c16(a).
c15(a).
c16(a) :- c17(a).
c16(a).
c17(a) :- c18(a).
c17(a).
c18(a) :- c19(a).
c18(a).
c19(a) :- c20(a).
c19(a).
c20(a) :- c21(a).
c20(a).
c21(a) :- c22(a).
c21(a).
c22(a) :- c23(a).
c22(a).
c23(a) :- c24(a).
c23(a).
c24(a) :- c25(a).
c24(a).
c25(a) :- c26(a).
c25(a).
c26(a) :- c27(a).
c26(a).
c27(a) :- c28(a).
c27(a).
c28(a) :- c29(a).
c28(a).
c29(a) :- c30(a).
c29(a).
c30(a) :- c31(a).
c30(a).
c31(a) :- c32(a).
c31(a).
c32(a) :- c33(a).
c32(a).
c33(a) :- c34(a).
c33(a).
c34(a) :- c35(a).
c34(a).
c35(a) :- c36(a).
c35(a).
c36(a) :- c37(a).
c36(a).
c37(a) :- c38(a).
c37(a).
c38(a) :- c39(a).
c38(a).
c39(a) :- c40(a).
c39(a).
c40(a) :- c41(a).
c40(a).
c41(a) :- c42(a).
c41(a).
c42(a) :- c43(a).
c42(a).
c43(a) :- c44(a).
c43(a).
c44(a) :- c45(a).
c44(a).
c45(a) :- c46(a).
c45(a).
c46(a) :- c47(a).
c46(a).
c47(a) :- c48(a).
c47(a).
c48(a) :- c49(a).
c48(a).
c49(a) :- c50(a).
c49(a).
c50(a) :- c51(a).
c50(a).
c51(a) :- c52(a).
c51(a).
c52(a) :- c53(a).
c52(a).
c53(a) :- c54(a).
c53(a).
c54(a) :- c55(a).
c54(a).
c55(a) :- c56(a).
c55(a).
c56(a) :- c57(a).
c56(a).
c57(a) :- c58(a).
c57(a).
c58(a) :- c59(a).
c58(a).
c59(a) :- c60(a).
c59(a).
c60(a) :- c61(a).
c60(a).
c61(a) :- c62(a).
c61(a).
c62(a) :- c63(a).
c62(a).
c63(a) :- c64(a).
c63(a).
c64(a) :- c65(a).
c64(a).
c65(a) :- c66(a).
c65(a).
c66(a) :- c67(a).
c66(a).
c67(a) :- c68(a).
c67(a).
c68(a) :- c69(a).
c68(a).
c69(a) :- c70(a).
c69(a).
c70(a) :- c71(a).
c70(a).
c71(a) :- c72(a).
c71(a).
c72(a) :- c73(a).
c72(a).
c73(a) :- c74(a).
c73(a).
c74(a) :- c75(a).
c74(a).
c75(a) :- c76(a).
c75(a).
c76(a) :- c77(a).
c76(a).
c77(a) :- c78(a).
c77(a).
c78(a) :- c79(a).
c78(a).
c79(a) :- c80(a).
c79(a).
c80(a) :- c81(a).
c80(a).
c81(a) :- c82(a).
c81(a).
c82(a) :- c83(a).
c82(a).
c83(a) :- c84(a).
c83(a).
c84(a) :- c85(a).
c84(a).
c85(a) :- c86(a).
c85(a).
c86(a) :- c87(a).
c86(a).
c87(a) :- c88(a).
c87(a).
c88(a) :- c89(a).
c88(a).
c89(a) :- c90(a).
c89(a).
c90(a) :- c91(a).
c90(a).
c91(a) :- c92(a).
c91(a).
c92(a) :- c93(a).
c92(a).
c93(a) :- c94(a).
c93(a).
c94(a) :- c95(a).
c94(a).
c95(a) :- c96(a).
c95(a).
c96(a) :- c97(a).
c96(a).
c97(a) :- c98(a).
c97(a).
c98(a) :- c99(a).
c98(a).
c99(a) :- c100(a).
c99(a).
c100(a).
c100(a).
% 13. Create 100 choice points and trail 100 variables
bench_mark(trail_variables, 2000, trail, dummy).
:- public trail/0.
trail :- t1(_X), !.
t1(a) :- t2(_X).
t1(b).
t2(a) :- t3(_X).
t2(b).
t3(a) :- t4(_X).
t3(b).
t4(a) :- t5(_X).
t4(b).
t5(a) :- t6(_X).
t5(b).
t6(a) :- t7(_X).
t6(b).
t7(a) :- t8(_X).
t7(b).
t8(a) :- t9(_X).
t8(b).
t9(a) :- t10(_X).
t9(b).
t10(a) :- t11(_X).
t10(b).
t11(a) :- t12(_X).
t11(b).
t12(a) :- t13(_X).
t12(b).
t13(a) :- t14(_X).
t13(b).
t14(a) :- t15(_X).
t14(b).
t15(a) :- t16(_X).
t15(b).
t16(a) :- t17(_X).
t16(b).
t17(a) :- t18(_X).
t17(b).
t18(a) :- t19(_X).
t18(b).
t19(a) :- t20(_X).
t19(b).
t20(a) :- t21(_X).
t20(b).
t21(a) :- t22(_X).
t21(b).
t22(a) :- t23(_X).
t22(b).
t23(a) :- t24(_X).
t23(b).
t24(a) :- t25(_X).
t24(b).
t25(a) :- t26(_X).
t25(b).
t26(a) :- t27(_X).
t26(b).
t27(a) :- t28(_X).
t27(b).
t28(a) :- t29(_X).
t28(b).
t29(a) :- t30(_X).
t29(b).
t30(a) :- t31(_X).
t30(b).
t31(a) :- t32(_X).
t31(b).
t32(a) :- t33(_X).
t32(b).
t33(a) :- t34(_X).
t33(b).
t34(a) :- t35(_X).
t34(b).
t35(a) :- t36(_X).
t35(b).
t36(a) :- t37(_X).
t36(b).
t37(a) :- t38(_X).
t37(b).
t38(a) :- t39(_X).
t38(b).
t39(a) :- t40(_X).
t39(b).
t40(a) :- t41(_X).
t40(b).
t41(a) :- t42(_X).
t41(b).
t42(a) :- t43(_X).
t42(b).
t43(a) :- t44(_X).
t43(b).
t44(a) :- t45(_X).
t44(b).
t45(a) :- t46(_X).
t45(b).
t46(a) :- t47(_X).
t46(b).
t47(a) :- t48(_X).
t47(b).
t48(a) :- t49(_X).
t48(b).
t49(a) :- t50(_X).
t49(b).
t50(a) :- t51(_X).
t50(b).
t51(a) :- t52(_X).
t51(b).
t52(a) :- t53(_X).
t52(b).
t53(a) :- t54(_X).
t53(b).
t54(a) :- t55(_X).
t54(b).
t55(a) :- t56(_X).
t55(b).
t56(a) :- t57(_X).
t56(b).
t57(a) :- t58(_X).
t57(b).
t58(a) :- t59(_X).
t58(b).
t59(a) :- t60(_X).
t59(b).
t60(a) :- t61(_X).
t60(b).
t61(a) :- t62(_X).
t61(b).
t62(a) :- t63(_X).
t62(b).
t63(a) :- t64(_X).
t63(b).
t64(a) :- t65(_X).
t64(b).
t65(a) :- t66(_X).
t65(b).
t66(a) :- t67(_X).
t66(b).
t67(a) :- t68(_X).
t67(b).
t68(a) :- t69(_X).
t68(b).
t69(a) :- t70(_X).
t69(b).
t70(a) :- t71(_X).
t70(b).
t71(a) :- t72(_X).
t71(b).
t72(a) :- t73(_X).
t72(b).
t73(a) :- t74(_X).
t73(b).
t74(a) :- t75(_X).
t74(b).
t75(a) :- t76(_X).
t75(b).
t76(a) :- t77(_X).
t76(b).
t77(a) :- t78(_X).
t77(b).
t78(a) :- t79(_X).
t78(b).
t79(a) :- t80(_X).
t79(b).
t80(a) :- t81(_X).
t80(b).
t81(a) :- t82(_X).
t81(b).
t82(a) :- t83(_X).
t82(b).
t83(a) :- t84(_X).
t83(b).
t84(a) :- t85(_X).
t84(b).
t85(a) :- t86(_X).
t85(b).
t86(a) :- t87(_X).
t86(b).
t87(a) :- t88(_X).
t87(b).
t88(a) :- t89(_X).
t88(b).
t89(a) :- t90(_X).
t89(b).
t90(a) :- t91(_X).
t90(b).
t91(a) :- t92(_X).
t91(b).
t92(a) :- t93(_X).
t92(b).
t93(a) :- t94(_X).
t93(b).
t94(a) :- t95(_X).
t94(b).
t95(a) :- t96(_X).
t95(b).
t96(a) :- t97(_X).
t96(b).
t97(a) :- t98(_X).
t97(b).
t98(a) :- t99(_X).
t98(b).
t99(a) :- t100(_X).
t99(b).
t100(a).
t100(b).
% 14. Unify terms that are small in space but textually large.
bench_mark(medium_unify, 2000, equal(Term1, Term2), dummy(Term1, Term2)) :-
term64(Term1),
term64(Term2).
bench_mark(deep_unify, 100, equal(Term1, Term2), dummy(Term1, Term2)) :-
term4096(Term1),
term4096(Term2).
:- public equal/2.
equal(X, X).
term64(X1) :-
X1 = f(X2, X2),
X2 = f(X4, X4),
X4 = f(X8, X8),
X8 = f(X16, X16),
X16 = f(X32, X32),
X32 = f(X64, X64).
term4096(X1) :-
X1 = f(X2, X2),
X2 = f(X4, X4),
X4 = f(X8, X8),
X8 = f(X16, X16),
X16 = f(X32, X32),
X32 = f(X64, X64),
X64 = f(X128, X128),
X128 = f(X256, X256),
X256 = f(X512, X512),
X512 = f(X1024, X1024),
X1024 = f(X2048, X2048),
X2048 = f(X4096, X4096).
% 15. Do 100 integer additions nonrecursively,
% avoiding obvious compiler optimizations.
bench_mark(integer_add, 1000, a1(0, 1, R), dummy(0, 1, R)).
:- public a1/3.
a1(M, K, P) :- N is M + K, a2(N, 2, P).
a2(M, K, P) :- N is M + K, a3(N, 3, P).
a3(M, K, P) :- N is M + K, a4(N, 4, P).
a4(M, K, P) :- N is M + K, a5(N, 5, P).
a5(M, K, P) :- N is M + K, a6(N, 6, P).
a6(M, K, P) :- N is M + K, a7(N, 7, P).
a7(M, K, P) :- N is M + K, a8(N, 8, P).
a8(M, K, P) :- N is M + K, a9(N, 9, P).
a9(M, K, P) :- N is M + K, a10(N, 10, P).
a10(M, K, P) :- N is M + K, a11(N, 11, P).
a11(M, K, P) :- N is M + K, a12(N, 12, P).
a12(M, K, P) :- N is M + K, a13(N, 13, P).
a13(M, K, P) :- N is M + K, a14(N, 14, P).
a14(M, K, P) :- N is M + K, a15(N, 15, P).
a15(M, K, P) :- N is M + K, a16(N, 16, P).
a16(M, K, P) :- N is M + K, a17(N, 17, P).
a17(M, K, P) :- N is M + K, a18(N, 18, P).
a18(M, K, P) :- N is M + K, a19(N, 19, P).
a19(M, K, P) :- N is M + K, a20(N, 20, P).
a20(M, K, P) :- N is M + K, a21(N, 21, P).
a21(M, K, P) :- N is M + K, a22(N, 22, P).
a22(M, K, P) :- N is M + K, a23(N, 23, P).
a23(M, K, P) :- N is M + K, a24(N, 24, P).
a24(M, K, P) :- N is M + K, a25(N, 25, P).
a25(M, K, P) :- N is M + K, a26(N, 26, P).
a26(M, K, P) :- N is M + K, a27(N, 27, P).
a27(M, K, P) :- N is M + K, a28(N, 28, P).
a28(M, K, P) :- N is M + K, a29(N, 29, P).
a29(M, K, P) :- N is M + K, a30(N, 30, P).
a30(M, K, P) :- N is M + K, a31(N, 31, P).
a31(M, K, P) :- N is M + K, a32(N, 32, P).
a32(M, K, P) :- N is M + K, a33(N, 33, P).
a33(M, K, P) :- N is M + K, a34(N, 34, P).
a34(M, K, P) :- N is M + K, a35(N, 35, P).
a35(M, K, P) :- N is M + K, a36(N, 36, P).
a36(M, K, P) :- N is M + K, a37(N, 37, P).
a37(M, K, P) :- N is M + K, a38(N, 38, P).
a38(M, K, P) :- N is M + K, a39(N, 39, P).
a39(M, K, P) :- N is M + K, a40(N, 40, P).
a40(M, K, P) :- N is M + K, a41(N, 41, P).
a41(M, K, P) :- N is M + K, a42(N, 42, P).
a42(M, K, P) :- N is M + K, a43(N, 43, P).
a43(M, K, P) :- N is M + K, a44(N, 44, P).
a44(M, K, P) :- N is M + K, a45(N, 45, P).
a45(M, K, P) :- N is M + K, a46(N, 46, P).
a46(M, K, P) :- N is M + K, a47(N, 47, P).
a47(M, K, P) :- N is M + K, a48(N, 48, P).
a48(M, K, P) :- N is M + K, a49(N, 49, P).
a49(M, K, P) :- N is M + K, a50(N, 50, P).
a50(M, K, P) :- N is M + K, a51(N, 51, P).
a51(M, K, P) :- N is M + K, a52(N, 52, P).
a52(M, K, P) :- N is M + K, a53(N, 53, P).
a53(M, K, P) :- N is M + K, a54(N, 54, P).
a54(M, K, P) :- N is M + K, a55(N, 55, P).
a55(M, K, P) :- N is M + K, a56(N, 56, P).
a56(M, K, P) :- N is M + K, a57(N, 57, P).
a57(M, K, P) :- N is M + K, a58(N, 58, P).
a58(M, K, P) :- N is M + K, a59(N, 59, P).
a59(M, K, P) :- N is M + K, a60(N, 60, P).
a60(M, K, P) :- N is M + K, a61(N, 61, P).
a61(M, K, P) :- N is M + K, a62(N, 62, P).
a62(M, K, P) :- N is M + K, a63(N, 63, P).
a63(M, K, P) :- N is M + K, a64(N, 64, P).
a64(M, K, P) :- N is M + K, a65(N, 65, P).
a65(M, K, P) :- N is M + K, a66(N, 66, P).
a66(M, K, P) :- N is M + K, a67(N, 67, P).
a67(M, K, P) :- N is M + K, a68(N, 68, P).
a68(M, K, P) :- N is M + K, a69(N, 69, P).
a69(M, K, P) :- N is M + K, a70(N, 70, P).
a70(M, K, P) :- N is M + K, a71(N, 71, P).
a71(M, K, P) :- N is M + K, a72(N, 72, P).
a72(M, K, P) :- N is M + K, a73(N, 73, P).
a73(M, K, P) :- N is M + K, a74(N, 74, P).
a74(M, K, P) :- N is M + K, a75(N, 75, P).
a75(M, K, P) :- N is M + K, a76(N, 76, P).
a76(M, K, P) :- N is M + K, a77(N, 77, P).
a77(M, K, P) :- N is M + K, a78(N, 78, P).
a78(M, K, P) :- N is M + K, a79(N, 79, P).
a79(M, K, P) :- N is M + K, a80(N, 80, P).
a80(M, K, P) :- N is M + K, a81(N, 81, P).
a81(M, K, P) :- N is M + K, a82(N, 82, P).
a82(M, K, P) :- N is M + K, a83(N, 83, P).
a83(M, K, P) :- N is M + K, a84(N, 84, P).
a84(M, K, P) :- N is M + K, a85(N, 85, P).
a85(M, K, P) :- N is M + K, a86(N, 86, P).
a86(M, K, P) :- N is M + K, a87(N, 87, P).
a87(M, K, P) :- N is M + K, a88(N, 88, P).
a88(M, K, P) :- N is M + K, a89(N, 89, P).
a89(M, K, P) :- N is M + K, a90(N, 90, P).
a90(M, K, P) :- N is M + K, a91(N, 91, P).
a91(M, K, P) :- N is M + K, a92(N, 92, P).
a92(M, K, P) :- N is M + K, a93(N, 93, P).
a93(M, K, P) :- N is M + K, a94(N, 94, P).
a94(M, K, P) :- N is M + K, a95(N, 95, P).
a95(M, K, P) :- N is M + K, a96(N, 96, P).
a96(M, K, P) :- N is M + K, a97(N, 97, P).
a97(M, K, P) :- N is M + K, a98(N, 98, P).
a98(M, K, P) :- N is M + K, a99(N, 99, P).
a99(M, K, P) :- N is M + K, a100(N, 100, P).
a100(M, K, P) :- P is M + K.
% 16. 100 floating additions
bench_mark(floating_add, 1000, fa1(0.1, 1.1, R), dummy(0.1, 1.1, R)).
:- public fa1/3.
fa1(M, K, P) :- N is M + K, fa2(N, 2.1, P).
fa2(M, K, P) :- N is M + K, fa3(N, 3.1, P).
fa3(M, K, P) :- N is M + K, fa4(N, 4.1, P).
fa4(M, K, P) :- N is M + K, fa5(N, 5.1, P).
fa5(M, K, P) :- N is M + K, fa6(N, 6.1, P).
fa6(M, K, P) :- N is M + K, fa7(N, 7.1, P).
fa7(M, K, P) :- N is M + K, fa8(N, 8.1, P).
fa8(M, K, P) :- N is M + K, fa9(N, 9.1, P).
fa9(M, K, P) :- N is M + K, fa10(N, 10.1, P).
fa10(M, K, P) :- N is M + K, fa11(N, 11.1, P).
fa11(M, K, P) :- N is M + K, fa12(N, 12.1, P).
fa12(M, K, P) :- N is M + K, fa13(N, 13.1, P).
fa13(M, K, P) :- N is M + K, fa14(N, 14.1, P).
fa14(M, K, P) :- N is M + K, fa15(N, 15.1, P).
fa15(M, K, P) :- N is M + K, fa16(N, 16.1, P).
fa16(M, K, P) :- N is M + K, fa17(N, 17.1, P).
fa17(M, K, P) :- N is M + K, fa18(N, 18.1, P).
fa18(M, K, P) :- N is M + K, fa19(N, 19.1, P).
fa19(M, K, P) :- N is M + K, fa20(N, 20.1, P).
fa20(M, K, P) :- N is M + K, fa21(N, 21.1, P).
fa21(M, K, P) :- N is M + K, fa22(N, 22.1, P).
fa22(M, K, P) :- N is M + K, fa23(N, 23.1, P).
fa23(M, K, P) :- N is M + K, fa24(N, 24.1, P).
fa24(M, K, P) :- N is M + K, fa25(N, 25.1, P).
fa25(M, K, P) :- N is M + K, fa26(N, 26.1, P).
fa26(M, K, P) :- N is M + K, fa27(N, 27.1, P).
fa27(M, K, P) :- N is M + K, fa28(N, 28.1, P).
fa28(M, K, P) :- N is M + K, fa29(N, 29.1, P).
fa29(M, K, P) :- N is M + K, fa30(N, 30.1, P).
fa30(M, K, P) :- N is M + K, fa31(N, 31.1, P).
fa31(M, K, P) :- N is M + K, fa32(N, 32.1, P).
fa32(M, K, P) :- N is M + K, fa33(N, 33.1, P).
fa33(M, K, P) :- N is M + K, fa34(N, 34.1, P).
fa34(M, K, P) :- N is M + K, fa35(N, 35.1, P).
fa35(M, K, P) :- N is M + K, fa36(N, 36.1, P).
fa36(M, K, P) :- N is M + K, fa37(N, 37.1, P).
fa37(M, K, P) :- N is M + K, fa38(N, 38.1, P).
fa38(M, K, P) :- N is M + K, fa39(N, 39.1, P).
fa39(M, K, P) :- N is M + K, fa40(N, 40.1, P).
fa40(M, K, P) :- N is M + K, fa41(N, 41.1, P).
fa41(M, K, P) :- N is M + K, fa42(N, 42.1, P).
fa42(M, K, P) :- N is M + K, fa43(N, 43.1, P).
fa43(M, K, P) :- N is M + K, fa44(N, 44.1, P).
fa44(M, K, P) :- N is M + K, fa45(N, 45.1, P).
fa45(M, K, P) :- N is M + K, fa46(N, 46.1, P).
fa46(M, K, P) :- N is M + K, fa47(N, 47.1, P).
fa47(M, K, P) :- N is M + K, fa48(N, 48.1, P).
fa48(M, K, P) :- N is M + K, fa49(N, 49.1, P).
fa49(M, K, P) :- N is M + K, fa50(N, 50.1, P).
fa50(M, K, P) :- N is M + K, fa51(N, 51.1, P).
fa51(M, K, P) :- N is M + K, fa52(N, 52.1, P).
fa52(M, K, P) :- N is M + K, fa53(N, 53.1, P).
fa53(M, K, P) :- N is M + K, fa54(N, 54.1, P).
fa54(M, K, P) :- N is M + K, fa55(N, 55.1, P).
fa55(M, K, P) :- N is M + K, fa56(N, 56.1, P).
fa56(M, K, P) :- N is M + K, fa57(N, 57.1, P).
fa57(M, K, P) :- N is M + K, fa58(N, 58.1, P).
fa58(M, K, P) :- N is M + K, fa59(N, 59.1, P).
fa59(M, K, P) :- N is M + K, fa60(N, 60.1, P).
fa60(M, K, P) :- N is M + K, fa61(N, 61.1, P).
fa61(M, K, P) :- N is M + K, fa62(N, 62.1, P).
fa62(M, K, P) :- N is M + K, fa63(N, 63.1, P).
fa63(M, K, P) :- N is M + K, fa64(N, 64.1, P).
fa64(M, K, P) :- N is M + K, fa65(N, 65.1, P).
fa65(M, K, P) :- N is M + K, fa66(N, 66.1, P).
fa66(M, K, P) :- N is M + K, fa67(N, 67.1, P).
fa67(M, K, P) :- N is M + K, fa68(N, 68.1, P).
fa68(M, K, P) :- N is M + K, fa69(N, 69.1, P).
fa69(M, K, P) :- N is M + K, fa70(N, 70.1, P).
fa70(M, K, P) :- N is M + K, fa71(N, 71.1, P).
fa71(M, K, P) :- N is M + K, fa72(N, 72.1, P).
fa72(M, K, P) :- N is M + K, fa73(N, 73.1, P).
fa73(M, K, P) :- N is M + K, fa74(N, 74.1, P).
fa74(M, K, P) :- N is M + K, fa75(N, 75.1, P).
fa75(M, K, P) :- N is M + K, fa76(N, 76.1, P).
fa76(M, K, P) :- N is M + K, fa77(N, 77.1, P).
fa77(M, K, P) :- N is M + K, fa78(N, 78.1, P).
fa78(M, K, P) :- N is M + K, fa79(N, 79.1, P).
fa79(M, K, P) :- N is M + K, fa80(N, 80.1, P).
fa80(M, K, P) :- N is M + K, fa81(N, 81.1, P).
fa81(M, K, P) :- N is M + K, fa82(N, 82.1, P).
fa82(M, K, P) :- N is M + K, fa83(N, 83.1, P).
fa83(M, K, P) :- N is M + K, fa84(N, 84.1, P).
fa84(M, K, P) :- N is M + K, fa85(N, 85.1, P).
fa85(M, K, P) :- N is M + K, fa86(N, 86.1, P).
fa86(M, K, P) :- N is M + K, fa87(N, 87.1, P).
fa87(M, K, P) :- N is M + K, fa88(N, 88.1, P).
fa88(M, K, P) :- N is M + K, fa89(N, 89.1, P).
fa89(M, K, P) :- N is M + K, fa90(N, 90.1, P).
fa90(M, K, P) :- N is M + K, fa91(N, 91.1, P).
fa91(M, K, P) :- N is M + K, fa92(N, 92.1, P).
fa92(M, K, P) :- N is M + K, fa93(N, 93.1, P).
fa93(M, K, P) :- N is M + K, fa94(N, 94.1, P).
fa94(M, K, P) :- N is M + K, fa95(N, 95.1, P).
fa95(M, K, P) :- N is M + K, fa96(N, 96.1, P).
fa96(M, K, P) :- N is M + K, fa97(N, 97.1, P).
fa97(M, K, P) :- N is M + K, fa98(N, 98.1, P).
fa98(M, K, P) :- N is M + K, fa99(N, 99.1, P).
fa99(M, K, P) :- N is M + K, fa100(N, 100.1, P).
fa100(M, K, P) :- P is M + K.
% 17. 100 calls to arg at position N
bench_mark(arg(N), 2000, arg1(N, Term, R), dummy(N, Term, R)) :-
args(N),
complex_nary_term(100, N, Term).
:- public arg1/3.
complex_nary_term(0, N, N) :- !.
complex_nary_term(I, N, Term) :-
I > 0, J is I - 1,
complex_nary_term(J, N, SubTerm),
nary_term(N, SubTerm, Term).
nary_term(N, SubTerm, Term) :-
functor(Term, f, N),
fill_nary_term(N, SubTerm, Term).
fill_nary_term(0, _, _) :- !.
fill_nary_term(N, SubTerm, Term) :-
N > 0, M is N - 1,
arg(N, Term, SubTerm),
fill_nary_term(M, SubTerm, Term).
arg1(N, T, R) :- arg(N, T, X), arg2(N, X, R).
arg2(N, T, R) :- arg(N, T, X), arg3(N, X, R).
arg3(N, T, R) :- arg(N, T, X), arg4(N, X, R).
arg4(N, T, R) :- arg(N, T, X), arg5(N, X, R).
arg5(N, T, R) :- arg(N, T, X), arg6(N, X, R).
arg6(N, T, R) :- arg(N, T, X), arg7(N, X, R).
arg7(N, T, R) :- arg(N, T, X), arg8(N, X, R).
arg8(N, T, R) :- arg(N, T, X), arg9(N, X, R).
arg9(N, T, R) :- arg(N, T, X), arg10(N, X, R).
arg10(N, T, R) :- arg(N, T, X), arg11(N, X, R).
arg11(N, T, R) :- arg(N, T, X), arg12(N, X, R).
arg12(N, T, R) :- arg(N, T, X), arg13(N, X, R).
arg13(N, T, R) :- arg(N, T, X), arg14(N, X, R).
arg14(N, T, R) :- arg(N, T, X), arg15(N, X, R).
arg15(N, T, R) :- arg(N, T, X), arg16(N, X, R).
arg16(N, T, R) :- arg(N, T, X), arg17(N, X, R).
arg17(N, T, R) :- arg(N, T, X), arg18(N, X, R).
arg18(N, T, R) :- arg(N, T, X), arg19(N, X, R).
arg19(N, T, R) :- arg(N, T, X), arg20(N, X, R).
arg20(N, T, R) :- arg(N, T, X), arg21(N, X, R).
arg21(N, T, R) :- arg(N, T, X), arg22(N, X, R).
arg22(N, T, R) :- arg(N, T, X), arg23(N, X, R).
arg23(N, T, R) :- arg(N, T, X), arg24(N, X, R).
arg24(N, T, R) :- arg(N, T, X), arg25(N, X, R).
arg25(N, T, R) :- arg(N, T, X), arg26(N, X, R).
arg26(N, T, R) :- arg(N, T, X), arg27(N, X, R).
arg27(N, T, R) :- arg(N, T, X), arg28(N, X, R).
arg28(N, T, R) :- arg(N, T, X), arg29(N, X, R).
arg29(N, T, R) :- arg(N, T, X), arg30(N, X, R).
arg30(N, T, R) :- arg(N, T, X), arg31(N, X, R).
arg31(N, T, R) :- arg(N, T, X), arg32(N, X, R).
arg32(N, T, R) :- arg(N, T, X), arg33(N, X, R).
arg33(N, T, R) :- arg(N, T, X), arg34(N, X, R).
arg34(N, T, R) :- arg(N, T, X), arg35(N, X, R).
arg35(N, T, R) :- arg(N, T, X), arg36(N, X, R).
arg36(N, T, R) :- arg(N, T, X), arg37(N, X, R).
arg37(N, T, R) :- arg(N, T, X), arg38(N, X, R).
arg38(N, T, R) :- arg(N, T, X), arg39(N, X, R).
arg39(N, T, R) :- arg(N, T, X), arg40(N, X, R).
arg40(N, T, R) :- arg(N, T, X), arg41(N, X, R).
arg41(N, T, R) :- arg(N, T, X), arg42(N, X, R).
arg42(N, T, R) :- arg(N, T, X), arg43(N, X, R).
arg43(N, T, R) :- arg(N, T, X), arg44(N, X, R).
arg44(N, T, R) :- arg(N, T, X), arg45(N, X, R).
arg45(N, T, R) :- arg(N, T, X), arg46(N, X, R).
arg46(N, T, R) :- arg(N, T, X), arg47(N, X, R).
arg47(N, T, R) :- arg(N, T, X), arg48(N, X, R).
arg48(N, T, R) :- arg(N, T, X), arg49(N, X, R).
arg49(N, T, R) :- arg(N, T, X), arg50(N, X, R).
arg50(N, T, R) :- arg(N, T, X), arg51(N, X, R).
arg51(N, T, R) :- arg(N, T, X), arg52(N, X, R).
arg52(N, T, R) :- arg(N, T, X), arg53(N, X, R).
arg53(N, T, R) :- arg(N, T, X), arg54(N, X, R).
arg54(N, T, R) :- arg(N, T, X), arg55(N, X, R).
arg55(N, T, R) :- arg(N, T, X), arg56(N, X, R).
arg56(N, T, R) :- arg(N, T, X), arg57(N, X, R).
arg57(N, T, R) :- arg(N, T, X), arg58(N, X, R).
arg58(N, T, R) :- arg(N, T, X), arg59(N, X, R).
arg59(N, T, R) :- arg(N, T, X), arg60(N, X, R).
arg60(N, T, R) :- arg(N, T, X), arg61(N, X, R).
arg61(N, T, R) :- arg(N, T, X), arg62(N, X, R).
arg62(N, T, R) :- arg(N, T, X), arg63(N, X, R).
arg63(N, T, R) :- arg(N, T, X), arg64(N, X, R).
arg64(N, T, R) :- arg(N, T, X), arg65(N, X, R).
arg65(N, T, R) :- arg(N, T, X), arg66(N, X, R).
arg66(N, T, R) :- arg(N, T, X), arg67(N, X, R).
arg67(N, T, R) :- arg(N, T, X), arg68(N, X, R).
arg68(N, T, R) :- arg(N, T, X), arg69(N, X, R).
arg69(N, T, R) :- arg(N, T, X), arg70(N, X, R).
arg70(N, T, R) :- arg(N, T, X), arg71(N, X, R).
arg71(N, T, R) :- arg(N, T, X), arg72(N, X, R).
arg72(N, T, R) :- arg(N, T, X), arg73(N, X, R).
arg73(N, T, R) :- arg(N, T, X), arg74(N, X, R).
arg74(N, T, R) :- arg(N, T, X), arg75(N, X, R).
arg75(N, T, R) :- arg(N, T, X), arg76(N, X, R).
arg76(N, T, R) :- arg(N, T, X), arg77(N, X, R).
arg77(N, T, R) :- arg(N, T, X), arg78(N, X, R).
arg78(N, T, R) :- arg(N, T, X), arg79(N, X, R).
arg79(N, T, R) :- arg(N, T, X), arg80(N, X, R).
arg80(N, T, R) :- arg(N, T, X), arg81(N, X, R).
arg81(N, T, R) :- arg(N, T, X), arg82(N, X, R).
arg82(N, T, R) :- arg(N, T, X), arg83(N, X, R).
arg83(N, T, R) :- arg(N, T, X), arg84(N, X, R).
arg84(N, T, R) :- arg(N, T, X), arg85(N, X, R).
arg85(N, T, R) :- arg(N, T, X), arg86(N, X, R).
arg86(N, T, R) :- arg(N, T, X), arg87(N, X, R).
arg87(N, T, R) :- arg(N, T, X), arg88(N, X, R).
arg88(N, T, R) :- arg(N, T, X), arg89(N, X, R).
arg89(N, T, R) :- arg(N, T, X), arg90(N, X, R).
arg90(N, T, R) :- arg(N, T, X), arg91(N, X, R).
arg91(N, T, R) :- arg(N, T, X), arg92(N, X, R).
arg92(N, T, R) :- arg(N, T, X), arg93(N, X, R).
arg93(N, T, R) :- arg(N, T, X), arg94(N, X, R).
arg94(N, T, R) :- arg(N, T, X), arg95(N, X, R).
arg95(N, T, R) :- arg(N, T, X), arg96(N, X, R).
arg96(N, T, R) :- arg(N, T, X), arg97(N, X, R).
arg97(N, T, R) :- arg(N, T, X), arg98(N, X, R).
arg98(N, T, R) :- arg(N, T, X), arg99(N, X, R).
arg99(N, T, R) :- arg(N, T, X), arg100(N, X, R).
arg100(N, T, R) :- arg(N, T, R).
% 18. 100 indexed calls; some systems may require extra declarations to
% put an index on the first argument.
bench_mark(index, 2000, ix(1), dummy(1)).
:- public ix/1.
ix(1) :- ix(10000).
ix(4).
ix(9) :- ix(4).
ix(16) :- ix(9).
ix(25) :- ix(16).
ix(36) :- ix(25).
ix(49) :- ix(36).
ix(64) :- ix(49).
ix(81) :- ix(64).
ix(100) :- ix(81).
ix(121) :- ix(100).
ix(144) :- ix(121).
ix(169) :- ix(144).
ix(196) :- ix(169).
ix(225) :- ix(196).
ix(256) :- ix(225).
ix(289) :- ix(256).
ix(324) :- ix(289).
ix(361) :- ix(324).
ix(400) :- ix(361).
ix(441) :- ix(400).
ix(484) :- ix(441).
ix(529) :- ix(484).
ix(576) :- ix(529).
ix(625) :- ix(576).
ix(676) :- ix(625).
ix(729) :- ix(676).
ix(784) :- ix(729).
ix(841) :- ix(784).
ix(900) :- ix(841).
ix(961) :- ix(900).
ix(1024) :- ix(961).
ix(1089) :- ix(1024).
ix(1156) :- ix(1089).
ix(1225) :- ix(1156).
ix(1296) :- ix(1225).
ix(1369) :- ix(1296).
ix(1444) :- ix(1369).
ix(1521) :- ix(1444).
ix(1600) :- ix(1521).
ix(1681) :- ix(1600).
ix(1764) :- ix(1681).
ix(1849) :- ix(1764).
ix(1936) :- ix(1849).
ix(2025) :- ix(1936).
ix(2116) :- ix(2025).
ix(2209) :- ix(2116).
ix(2304) :- ix(2209).
ix(2401) :- ix(2304).
ix(2500) :- ix(2401).
ix(2601) :- ix(2500).
ix(2704) :- ix(2601).
ix(2809) :- ix(2704).
ix(2916) :- ix(2809).
ix(3025) :- ix(2916).
ix(3136) :- ix(3025).
ix(3249) :- ix(3136).
ix(3364) :- ix(3249).
ix(3481) :- ix(3364).
ix(3600) :- ix(3481).
ix(3721) :- ix(3600).
ix(3844) :- ix(3721).
ix(3969) :- ix(3844).
ix(4096) :- ix(3969).
ix(4225) :- ix(4096).
ix(4356) :- ix(4225).
ix(4489) :- ix(4356).
ix(4624) :- ix(4489).
ix(4761) :- ix(4624).
ix(4900) :- ix(4761).
ix(5041) :- ix(4900).
ix(5184) :- ix(5041).
ix(5329) :- ix(5184).
ix(5476) :- ix(5329).
ix(5625) :- ix(5476).
ix(5776) :- ix(5625).
ix(5929) :- ix(5776).
ix(6084) :- ix(5929).
ix(6241) :- ix(6084).
ix(6400) :- ix(6241).
ix(6561) :- ix(6400).
ix(6724) :- ix(6561).
ix(6889) :- ix(6724).
ix(7056) :- ix(6889).
ix(7225) :- ix(7056).
ix(7396) :- ix(7225).
ix(7569) :- ix(7396).
ix(7744) :- ix(7569).
ix(7921) :- ix(7744).
ix(8100) :- ix(7921).
ix(8281) :- ix(8100).
ix(8464) :- ix(8281).
ix(8649) :- ix(8464).
ix(8836) :- ix(8649).
ix(9025) :- ix(8836).
ix(9216) :- ix(9025).
ix(9409) :- ix(9216).
ix(9604) :- ix(9409).
ix(9801) :- ix(9604).
ix(10000) :- ix(9801).
% 19. Make 1000 asserts of unit clauses
bench_mark(assert_unit, 1, assert_clauses(L), dummy(L)) :-
abolish(ua,3),
create_units(1, 1000, L).
:- public assert_clauses/1.
create_units(I, N, []) :- I > N, !.
create_units(I, N, [ua(K, X, f(K, X))|Rest]) :-
K is I * (1 + I//100),
J is I + 1,
create_units(J, N, Rest).
assert_clauses([]).
assert_clauses([Clause|Rest]) :-
assert(Clause),
assert_clauses(Rest).
% 20. Access 100 dynamically-created clauses with 1st arg. instantiated
bench_mark(access_unit, 100, access_dix(1, 1), dummy(1, 1)) :-
abolish(dix, 2),
dix_clauses(1, 100, L),
assert_clauses(L).
:- public access_dix/2.
dix_clauses(I, N, []) :- I > N, !.
dix_clauses(I, N, [dix(P, Q) | L]) :-
I =< N,
P is I*I,
R is 1 + (I+N-2) mod N,
Q is R*R,
J is I + 1,
dix_clauses(J, N, L).
access_dix(Start, End) :-
dix(Start, Where),
( Where = End -> true | access_dix(Where, End) ).
% 21. Access 100 dynamic unit clauses (2nd argument instantiated)
:- public access_back/2.
bench_mark(slow_access_unit, 10, access_back(1, 1), dummy(1, 1)) :-
abolish(dix, 2),
dix_clauses(1, 100, L),
assert_clauses(L).
access_back(Start, End) :-
dix(Where, Start),
( Where = End -> true | access_back(Where, End) ).
% 22. Setof and bagof
bench_mark(setof, 10, setof(X, Y↑pr(X, Y), S), dummy(X, Y↑pr(X, Y), S)).
bench_mark(pair_setof, 10,
setof((X,Y), pr(X, Y), S),
dummy((X,Y), pr(X, Y), S)).
bench_mark(double_setof, 10, setof((X,S), setof(Y, pr(X, Y), S), T),
dummy(S, setof(Y, pr(X, Y), S), T)).
bench_mark(bagof, 10, bagof(X, Y↑pr(X, Y), S), dummy(X, Y↑pr(X, Y), S)).
pr(99, 1).
pr(98, 2).
pr(97, 3).
pr(96, 4).
pr(95, 5).
pr(94, 6).
pr(93, 7).
pr(92, 8).
pr(91, 9).
pr(90, 10).
pr(89, 11).
pr(88, 12).
pr(87, 13).
pr(86, 14).
pr(85, 15).
pr(84, 16).
pr(83, 17).
pr(82, 18).
pr(81, 19).
pr(80, 20).
pr(79, 21).
pr(78, 22).
pr(77, 23).
pr(76, 24).
pr(75, 25).
pr(74, 26).
pr(73, 27).
pr(72, 28).
pr(71, 29).
pr(70, 30).
pr(69, 31).
pr(68, 32).
pr(67, 33).
pr(66, 34).
pr(65, 35).
pr(64, 36).
pr(63, 37).
pr(62, 38).
pr(61, 39).
pr(60, 40).
pr(59, 41).
pr(58, 42).
pr(57, 43).
pr(56, 44).
pr(55, 45).
pr(54, 46).
pr(53, 47).
pr(52, 48).
pr(51, 49).
pr(50, 50).
pr(49, 51).
pr(48, 52).
pr(47, 53).
pr(46, 54).
pr(45, 55).
pr(44, 56).
pr(43, 57).
pr(42, 58).
pr(41, 59).
pr(40, 60).
pr(39, 61).
pr(38, 62).
pr(37, 63).
pr(36, 64).
pr(35, 65).
pr(34, 66).
pr(33, 67).
pr(32, 68).
pr(31, 69).
pr(30, 70).
pr(29, 71).
pr(28, 72).
pr(27, 73).
pr(26, 74).
pr(25, 75).
pr(24, 76).
pr(23, 77).
pr(22, 78).
pr(21, 79).
pr(20, 80).
pr(19, 81).
pr(18, 82).
pr(17, 83).
pr(16, 84).
pr(15, 85).
pr(14, 86).
pr(13, 87).
pr(12, 88).
pr(11, 89).
pr(10, 90).
pr(9, 91).
pr(8, 92).
pr(7, 93).
pr(6, 94).
pr(5, 95).
pr(4, 96).
pr(3, 97).
pr(2, 98).
pr(1, 99).
pr(0, 100).
------------------------------
End of PROLOG Digest
********************
∂06-Aug-87 1108 BERGMAN@Score.Stanford.EDU RAships
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Aug 87 11:08:33 PDT
Date: Thu 6 Aug 87 11:06:33-PDT
From: Sharon Bergman <BERGMAN@Score.Stanford.EDU>
Subject: RAships
To: faculty@Score.Stanford.EDU
Message-ID: <12324373672.22.BERGMAN@Score.Stanford.EDU>
Please send me a list of students you plan to support during the 1987-88
academic year along with their source of support. I need this information
soon since research assistant appointment forms are now due in the Graduate
Awards office. The forms need to be processed as soon as possible so that
the students receive their bills with the correct tuition applied.
Also, there is a list available of new incoming Ph.D. students with their
areas of interest. If you would like to look at the list with a view towards
possibly supporting some of these students, please let me know.
-Sharon Bergman
-------
∂06-Aug-87 1156 NILSSON@Score.Stanford.EDU committees
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Aug 87 11:55:55 PDT
Date: Thu 6 Aug 87 11:53:50-PDT
From: Nils Nilsson <NILSSON@Score.Stanford.EDU>
Subject: committees
To: faculty@Score.Stanford.EDU
Message-ID: <12324382281.30.NILSSON@Score.Stanford.EDU>
This note proposes CSD committees for 1987/1988. I've already talked to
some CSD faculty members about next year's committee staffing. We have
several faculty members on sabbatical during '87/'88, so it is even more
important than ever that we all try to do our fair share of committee
work. I have tried to use staff members as much as possible on those
committees most closely related to their work assignments; this will
help reduce faculty burden. But I see no way to deal with academic
matters (admissions, comprehensives) without imposing on the faculty.
One labor-saving innovation this year: I suggest we combine the PhD
program committee with the PhD admissions committee. There is much
overlap anyway in the work of these two groups.
Another, perhaps controversial suggestion: I have received several
negative comments about the CSD colloquium. The comments do not
criticize the speakers or the colloq organizers; rather they suggest
that the audience is generally uninterested (students more eager to sign
the attendance sheet than to hear what the speakers have to say) and
that few faculty members attend. Thus, it seems a waste of the
speakers' and of the organizers' time to put on a general CSD colloquium
series. There are several other specialized colloquia and talks (aflb,
databases, siglunch, ai research seminars, systems colloquia, etc), and
it has also been suggested that we might replace the general, weekly CSD
colloquium with a 6-times-a-year or so "distinguished speaker series."
Therefore, I propose that we abolish the CSD colloquium. (People who
want to persuade me otherwise will also either volunteer to organize it
or have volunteers in hand.)
The student bureaucrats should begin thinking about student members of
these committees as appropriate and let me know.
We will also have, from time to time, some ad hoc committees to consider
appointments/promotions. Many of us will also be involved, informally,
in helping the development office with fund-raising tasks. I expect also
that sometime after the first of January we will want to organize a
"building design committee." (Bob Floyd and Mike Genesereth have already
expressed interest in helping out here.)
Please let me know if you think I have erred badly in matching abilities
to tasks, but it would be unseemly to suggest adjustments whose main
effect is to distribute the workload unevenly. New faculty members who
have questions about these committees or their expected roles on them
should talk to me or the committee chair.
Thanks again for your continuing hard work and support. -Nils
PhD Program and Admissions: Decides which students admitted to CSD PhD
program. Recommends plans and policies for the PhD program. Supervises
Grey Tuesday/Black Friday proceedings. Arranges for ``research
mentors'' for first-year PhD students. Genesereth (Chair), Pratt,
Manna, Gupta, Gabriel (Lucid), Goldberg, Wiederhold, Floyd, Rosenschein
(SRI), Linton, Rick Reis (consulting member---Rick coordinates PhD
recruitment in SOE).
Comprehensive Exam: Conceives, administers and grades the two Comp
Exams. Last year was too much work for a single chair, and I suggest
that we have a different chair for each exam. (These chairs need be on
the committee only for the exam they are chairing.) Also, since we have
some people on sabbatical for parts of the year, I am suggesting that
some members will be on the committee for only one of the exams. Ullman
(Chair, first exam), Cheriton (Chair, second exam), Guibas (first exam),
Shoham (first exam), McCarthy (second exam), Mitchell (second exam),
Binford, Feigenbaum, Goldberg, Hennessy, Mayr
Curriculum: Decides about CSD courses.
Manna (Chair), Reges, Pratt, Knuth
Facilities: Recommends plans and policies for CSD computer facilities.
Earnest (Chair), Dienstbier, Rindfleisch, Ball, Binford
MS Program: Decides which students admitted to MS program. Recommends
plans and policies for MS program. Advises MS students. Oliger (Chair),
Floyd, Reges, McCluskey, Dill, Latombe, Baskett (Silicon Graphics),
Rindfleisch
MSAI Program: Decides which students admitted to MSAI program. Recommends
plans and policies for MSAI program. Advises MSAI students.
Buchanan (Chair), Clancey, Binford, Feigenbaum, Genesereth, Latombe
CSD Undergraduate Major: Recommends plans and policies for the major.
Arranges for advising students. Knuth (Chair), Reges, Jones, Rogers
Math/Comp. Sci. Major: Recommends plans and policies for the major.
Advises students.
Floyd, Herriot, Clancey, Reges
Computer Systems Engrg. Major: Recommends plans and policies for the major.
Advises students. Chair
Reges, Gupta
Symbolic Systems Major: Recommends plans and policies for the major.
Advises students.
Shoham, Mayr, Nilsson, Reges
Visiting Professors: Recommends Visiting Industrial Lectureships and
Departmental Visiting Professors.
McCarthy
Library and Publications: Recommends plans and policies for CSD library
and publication matters.
Buchanan (Chair), Scott
Fellowships: Recommends student fellowship disposition.
Tajnai (Chair), Nilsson, Scott
Computer Forum: Recommends plans and policies for the CSD/CSL industrial
affiliates program
Miller (Chair), Tajnai, Ungar, Pratt
First Year PhD Student Advisor:
Nilsson
-------
∂06-Aug-87 2003 @Score.Stanford.EDU:ZHULU@Sushi.Stanford.EDU short term lodging for new students
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Aug 87 20:02:54 PDT
Received: from Sushi.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 6 Aug 87 19:59:10-PDT
Date: Thu 6 Aug 87 19:58:53-PDT
From: David Zhu <ZHULU@Sushi.Stanford.EDU>
Subject: short term lodging for new students
To: students@Score.Stanford.EDU, staff@Score.Stanford.EDU,
faculty@Score.Stanford.EDU
Message-ID: <12324470580.8.ZHULU@Sushi.Stanford.EDU>
Dear Faculty members, staffs, and fellow students,
The orientation committee is still looking for volunteers to provide short term
(one to two days) lodging for new students(before they can move into their
permanent housing). Anything from floor space for a sleeping bag to a sofa
in the living room will do. If you are willing to volunteer, please send
your name, address, telephone numbers(home and/or work) to me(ZHULU@SUSHI).
Your generosity and hospitality will be greatly appreciated.
P.S. We have to compile a final list to be mailed to the new students tomorrow,
so a speedy reply will be helpful. But if you can't make the decision now, I
will be acting as a co-ordinator for this short term stay "project", so as long
as you can make up your mind before the end of september, let me know.
David Zhu
Orientation Committee '87
-------
-------
∂10-Aug-87 0116 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #57
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 10 Aug 87 01:16:54 PDT
Date: Sun 9 Aug 1987 14:14-PDT
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #57
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Monday, 10 Aug 1987 Volume 5 : Issue 57
Today's Topics:
Query - FBRL & Multiple Copies of a Clause,
----------------------------------------------------------------------
Date: 5 Aug 87 16:18:59 GMT
From: decvax!dartvax!uvm-gen!emerson@ucbvax.Berkeley.EDU
Subject: FBRL in Prolog
Does anyone know of any FBRL's written in Prolog or that support
logical inference? I know HSRL (from Carnegie-Mellon) and KRYPTON
(from XEROX PARC) have a logical basis to them, but both are written
in LISP.
I am currently writing a FBRL interpreter embedded in C-Prolog, and
would like to ''compare notes'' with other such systems, if they're
out there.
I would also appreciate any thoughts on the implementation of frame
theory in Prolog.
Thanks in advance,
-- Tom
------------------------------
Date: Sat, 8 Aug 87 00:54:28 EDT
From: Tim Finin <tim@linc.cis.upenn.edu>
Subject: FBRL
You may want to start by looking at Pat Hay's paper "The Logic of
Frames" from the mid to late seventies. He gives a logical account
for the semantics underlying the basic ideas in FBRL's. The paper is
reprinted in Brachman and Levesque's book "Readings in Knowledge
Representation" published by Morgan Kaufmann (1985).
I can point you toward three things involving FBRLs in Prolog that you
may want to look at:
[1] WIth a group from RCA, I built a frame-based representation
language in prolog called PINE. We used it to build an expert system
for diagnosing faults in ATE equipment. It is described in:
FOREST - An Expert System for Automatic Test Equipment; Tim Finin, Pamela
Kleinosky and John McAdams; Proceedings of the First Conference on
Artificial Intelligence Applications; (IEEE), Denver, Colorado, 1984.
A somewhat longer version is available as
technical report MS-CIS-84-09, Dept. of Computer and Information Science,
University of Pennsylvania, Philadelphia PA 19104
[2] Arity Corp offers an expert systems building toolkit (written by
David Drager) which is based on a FBRL. It's written in Arity Prolog,
of course. It is really quite powerful. I'd characterize it as a
cross between EMYCIN and KEE.
[3] The AI research group at UNISYS's Paoli Research Lab has been
using a FBRL implemented in Prolog to build many of their expert
systems for quite some time. There system is called KNET and is
similar to KL-ONE. An early reference is:
KNET - A logic Based Associative Network Framework for Expert
Systems"; Freeman, M., L. Hirschman and D. McKay; SDC, A Burroughs
Company; technical memo LBS 12; Sept. 1983.
I believe that there are several descriptions of it in the open
literature, but I'm not sure where they can be found.
-- Tim
------------------------------
Date: Fri, 7 Aug 87 09:53:27 EDT
From: Tim Finin <Tim@linc.cis.upenn.edu>
Subject: multiple copies of a clause in the DB
I'm studying various ways to extend Prolog's simple model of the
database (e.g. a flat, global collections of clauses) to a richer
hierarchical one with inheritance. I am trying to decide whether to
allow multiple instances of a clause in a resulting database view.
Most Prolog implementations, at least those descendant from DEC-10
Prolog, do allow the database to contain two identical clauses. Most
of the non-Prolog logic programming languages that I am familiar with
do not. I am interested in discovering what use, if any, people have
made of the ability to assert multiple copies of a clause into the
database.
I, for one, have never found a use for this in practice. In fact, it
has only effected my life by being a source of bugs. It is easy
enough to accidentally get multiple copies of a clause in the database
by consulting a file instead of reconsulting it or by defining the
same predicate in two different files. This can easily mess up your
program unless you use a rather pure logic programming style which
doen't depend on the order in which the clauses are stored in the
database.
Has anyone out there found a good use for this Prolog "feature"?
-- Tim
------------------------------
Date: 8 Aug 87 15:30:10 GMT
From: Saumya Debray <debray@arizona.edu>
Subject: Multiple Copies of a Clause in the DB
In my view, in this case the underlying implementation should provide
something that focuses on efficiency, without taking away from the
user the flexibility of imposing additional constraints if he so
desires. If I don't care about the presence of duplicate clauses, I
shouldn't have to pay the price of checking for duplicates; on the
other hand, if I do care about duplicates, it's easy enough to extend
"assert" to take care of this, e.g.:
my_assert((H :- B)) :- clause(H,B) -> true ; assert((H :- B)).
my_assert(Fact) :- clause(Fact,true) -> true ; assert(Fact).
Since "consult" is basically a read-assert loop, the analogous
extension of "consult" to "my_consult" is straightforward.
Such an approach is flexible enough to handle stronger notions of what
constitutes "redundancy" in the database as well, e.g. if I wanted to
ensure that only those facts were asserted that were not provable from
what's already in the database, I'd write something like
my_assert(X) :- not(X), assert(X). [*]
Of course, with this "my_assert" is no longer guaranteed to terminate,
but that's the user's problem.
[* This only works for ground facts, of course, but you see what I'm
getting at.]
In summary: language constructs should be designed so that (i) users
don't have to pay for features they don't use; and (ii) users should
have the flexibility of extending the basic language features to do
what they want without undue suffering.
-- Saumya Debray
------------------------------
End of PROLOG Digest
********************
∂10-Aug-87 0543 @Sushi.Stanford.EDU:THEORYNT%YKTVMZ.BITNET@forsythe.stanford.edu Logic In Computer Science (LICS) Call for Papers
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 10 Aug 87 05:43:23 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Mon 10 Aug 87 05:38:53-PDT
Received: by lindy.stanford.edu; Mon, 10 Aug 87 05:39:34 PDT
Resent-From: THEORYNT%YKTVMZ.BITNET@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Mon, 10 Aug 87 05:38:40 PDT
Date: Sat, 8 Aug 87 16:18 EDT
From: <BRAY%CLVMS.BITNET@forsythe.stanford.edu>
Subject: Logic In Computer Science (LICS) Call for Papers
Message-Id: <C088.THEORYNT@ibm.com>
Resent-Date: 10 Aug 1987 08:38:04-EDT (Monday)
Resent-Sender: THEORYNT%YKTVMZ.BITNET@forsythe.stanford.edu
Resent-To: aflb.tn@sushi.stanford.edu
Apparently-To: aflb.tn@SUSHI.STANFORD.EDU
-------------------------------------------------------------------------
CALL FOR PAPERS
THIRD ANNUAL SYMPOSIUM ON
LOGIC IN COMPUTER SCIENCE
5-8 July 1988
University of Edinburgh, Edinburgh, Scotland
Concepts and methods from Logic are influential throughout Computer Science.
The Annual IEEE Symposium on Logic in Computer Science (LICS) aims to attract
participation oc Computer Scientists, whose design or research activities
involve Logic, and Logicians interested in Computer Science. Suggested (but
not exclusive) topics of interest include: abstract data types, computer
theorem proving, concurrency, data base theory, knowledge representation,
finite model theory, lambda and combinatory calculi, logic programming, modal
and temporal logics, program logic and semantics, software specification, types
and categories, constructive mathematics, verification.
PROGRAM COMMITTEE: M. Dezani, Y. Gurevich (chair), J. Halpern, C.A.R. Hoare,
G. Huet, P. Kanellakis, J.-L. Lassez, J. Mitchell, R. Platek, G. Plotkin,
S. Rosenschein, P. Sistla, J. Tiuryn, M. Wand
PAPER SUBMISSION: Send 14 copies of an extended abstract to the program
chairman:
Yuri Gurevich - LICS (313) 971-2652
Electrical Engineering and Yuri_Gurevich@um.cc.umich.edu
Computer Science Dept.
University of Michigan
Ann Arbor, Michigan 48109-2122
The package must be airmail postmarked by 27 NOVEMBER 1987 or received by 4
DECEMBER 1987. Abstract should be clearly written and provide sufficient
detail to allow the program committee to assess the merits of the paper.
References and comparisons with related work should be included where
appropriate. The entire extended abstract should not exceed 10 double-spaced
pages in 10 or 12-point fonts. Late abstracts or abstract departing
significantly from these guidlines run a high risk of not being considered. If
a copier is not available to the author, a single copy of the abstract will do.
Author will be notified of acceptance of rejection by 27 JANUARY 1988.
Accepted papers, typed on special forms for inclusion in the symposium
proceedings, will be due 14 MARCH 1988.
The symposium is sponsored by the IEEE Computer Society, Technical Committee on
Mathematical Foundations of Computing, and the University of Edinburgh, in
cooperation with ACM SIGACT, ASL, and EATCS.
ORGANIZING COMMITTEE: J. Barwise, W. Bledsoe, A. Chandra (chair), E. Dijkstra,
E. Engeler, J. Goguen, D. Gries, D. Kozen, Z. Manna, A. Meyer, R. Parikh,
G. Plotkin, D. Scott
GENERAL CHAIRMAN: LOCAL ARRANGEMENTS:
Ashok K. Chandra George Cleland
IBM Thomas J. Watson Department of Computer Science
Research Center The King's Buildings
P.O. Box 218 University of Edinburgh
Yorktown Heights, NY 10598 Edinburgh EH9 3JZ, SCOTLAND
(914) 945-1752 011 44 31 667 1081 ext. 2775
ashok@ibm.com glc%lfcs.edingurgh.ac.uk@ucl-cs.arpa
-------
∂10-Aug-87 1219 PAPA@score.stanford.edu Chain Rule Paper
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 10 Aug 87 12:19:52 PDT
Received: from Score.Stanford.EDU by navajo.stanford.edu with TCP; Mon, 10 Aug 87 12:12:21 PDT
Date: Mon 10 Aug 87 10:24:47-PDT
From: C. Papadimitriou <PAPA@score.stanford.edu>
Subject: Chain Rule Paper
To: paco@navajo.stanford.edu, nail@navajo.stanford.edu
Cc: rn@sail.stanford.edu
Message-Id: <12325414646.48.PAPA@Score.Stanford.EDU>
The full version of the paper ``The Parallel Complexity of Simple Logic
Programs'' is now available. If you are interested, please stop by
Rosemary's office for your copy. Please give me your comments ASAP.
---Christos.
-------
∂10-Aug-87 1441 LES Facilities Committee Special Meeting
To: "@FACIL.DIS[P,DOC]"@SAIL.STANFORD.EDU, Nilsson@SCORE.STANFORD.EDU,
BScott@SCORE.STANFORD.EDU, Reges@SCORE.STANFORD.EDU
I propose that the CS Facilities Committee meet this Wednesday, August 12,
at 1:15pm in the Chairman's Conference Room (Jacks 220) to discuss a
possible semi-radical departure from current plans, as outlined below.
There appears to be an opportunity to substantially reduce CSD
expenditures for computer services by taking advantage of an offer from
LOTS (or HOTS or whatever they call themselves now).
LOTS recently purchased a DEC VAX-8800 which is scheduled to take over the
name "Portia" from the existing 8650 and be made available for general
student computing, including CS students. It appears that this would
provide adequate support for the foreseeable future for general student use,
including unsponsored research.
We had planned to replace Sushi and Navajo with a new DEC VAX 8700, most
of which would have had to be paid for out of departmental gift funds.
A cancellable order was placed with DEC, with the last date for
cancellation being later this month (8/27 apparently).
This gives us an opportunity to shift the expense of student computing to
the university, where many of us believe that it belongs. The sensible
plan (in my view) is:
(1) cancel the 8700 order;
(2) move most students to the new Portia (except those who are strongly
tied by software to TOPS-20 -- they would be given accounts on Score;
(3) shut down Sushi, probably sometime during the Autumn Quarter;
(4) continue to operate Navajo for the foreseeable future, with the
expectation that a new Unix mainframe will be purchased sometime
in the next 3 years or so to replace Navajo and another system
(e.g. SAIL or Score).
I estimate that this plan will save the department something over $100k
per year, permitting our limited gift funds to be put to better use.
I invite committee members to review the issues and any other possible
alternative plans with the aim of reaching a consensus recommendation.
Les Earnest
∂10-Aug-87 1448 @Sushi.Stanford.EDU:PAPA@Score.Stanford.EDU Address
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 10 Aug 87 14:48:44 PDT
Received: from Score.Stanford.EDU by Sushi.Stanford.EDU with TCP; Mon 10 Aug 87 14:45:11-PDT
Date: Mon 10 Aug 87 14:45:20-PDT
From: C. Papadimitriou <PAPA@Score.Stanford.EDU>
Subject: Address
To: aflb.local@Score.Stanford.EDU
Message-ID: <12325462078.38.PAPA@Score.Stanford.EDU>
Does anybody know the address of M. J. Atallah (and cares to share it with me)?
Thanks! ----Christos.
-------
∂10-Aug-87 1718 RINDFLEISCH@SUMEX-AIM.STANFORD.EDU Re: Facilities Committee Special Meeting
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 10 Aug 87 17:18:15 PDT
Date: Mon, 10 Aug 87 17:18:05 PDT
From: TC Rindfleisch <Rindfleisch@SUMEX-AIM.STANFORD.EDU>
Subject: Re: Facilities Committee Special Meeting
To: LES@SAIL.STANFORD.EDU, "@FACIL.DIS[P,DOC]"@SAIL.STANFORD.EDU,
Nilsson%SCORE.STANFORD.EDU@SUMEX-AIM.STANFORD.EDU,
BScott%SCORE.STANFORD.EDU@SUMEX-AIM.STANFORD.EDU,
Reges%SCORE.STANFORD.EDU@SUMEX-AIM.STANFORD.EDU
cc: Rindfleisch@SUMEX-AIM.STANFORD.EDU
In-Reply-To: Message from "Les Earnest <LES@SAIL.STANFORD.EDU>" of Mon, 10 Aug 87 14:41:00 PDT
Message-ID: <12325489885.17.RINDFLEISCH@SUMEX-AIM.STANFORD.EDU>
Les, I can't make a CS Facilities meeting Wed at 1:15 because of a prior lunch
commitment. 2:00 on Wed would be a much more convenient time for me.
Re the VAX upgrade plan, I agree completely about transferring the cost of
student support to Street. We will need to have answers to some questions
though, like:
1) How much capacity of the 8800 will be available for CS students as compared
to what they would have had access to on the 8700?
2) What are the operations and software policies of AIR w/r to the needs of CS
students, i.e., can we get the disk space, memory allocations, software, etc.
we need from the Portia folks?
3) Are there any hidden costs to the CSD or SOE of transferring our student
load to Portia, e.g., reductions in other monies coming for computing support
or the undergraduate program?
Tom R.
-------
∂11-Aug-87 1532 TOM@Score.Stanford.EDU Re: Facilities Committee Special Meeting
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Aug 87 15:32:15 PDT
Date: Tue 11 Aug 87 15:29:39-PDT
From: Thomas Dienstbier <TOM@Score.Stanford.EDU>
Subject: Re: Facilities Committee Special Meeting
To: LES@Sail.Stanford.EDU
cc: "@FACIL.DIS[P,DOC]"@Sail.Stanford.EDU, Nilsson@Score.Stanford.EDU,
BScott@Score.Stanford.EDU, Reges@Score.Stanford.EDU, TOM@Score.Stanford.EDU
In-Reply-To: Message from "Les Earnest <LES@SAIL.STANFORD.EDU>" of Mon 10 Aug 87 14:41:00-PDT
Message-ID: <12325732287.26.TOM@Score.Stanford.EDU>
I am not sure who is on what list at this time,,some of you have seen
this.
Some ideas that I have on Ralphs offer of UNIX cycles.
I think that Ralph is to be commended for his offer since I believe he had not
planned on CSD students for using his machine when it was ordered.
Part 1.
Some clarification when we speak of students do we only mean under-graduate,
masters,phd? Sushi currently supports all of the above. Will the students
still receive the same usage as they are accustom to??
As we may remember the reason that we have Sushi is that Lots, or what ever,
could not provide the type of service that we, the department, felt our
students deserve. High load averages,login ques, not enough disk space. I don't
think that our students want to go back to the night shift to be able to do
any reasonable work. We are a small number of students that Raplh has
to support but are large computer hogs.
Is Lots going to provide networking, tips and terminal service for our
students? Remember CSDCF does provide this as part of the cost/service.
Do we have any say on what the LOTS machine run or what it should provide?
Part 2.
Have we totally forgotten the sponsored project use of NAvajo, which we need to
also upgrade? We need to provide the best type of service that we can, of
course within reason.
We are told that we are the top CSD in the nation,,how are we going to maintain
that position,,not by using machines(vax750,780,dec2060) or other antiquated
machines or by having to worry about being out of disk space/computer cycles?
Navajo usage if more than 10 users is basically unusable if for instance
someone is compiling. This sometimes may become 15 users before saturation
occures.
tom
-------
∂11-Aug-87 1627 PALLAS@Sushi.Stanford.EDU Re: Facilities Committee Special Meeting
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Aug 87 16:27:29 PDT
Date: Tue 11 Aug 87 16:26:30-PDT
From: Joseph I. Pallas <PALLAS@Sushi.Stanford.EDU>
Subject: Re: Facilities Committee Special Meeting
To: "@FACIL.DIS[P,DOC]"@Sail.Stanford.EDU
cc: Nilsson@Score.Stanford.EDU, BScott@Score.Stanford.EDU,
Reges@Score.Stanford.EDU
Message-ID: <12325742639.38.PALLAS@Sushi.Stanford.EDU>
There are a number of important issues that should be addressed before
such a significant change in plans is decided. I'd like to raise a
few in addition to those already mentioned.
First, and foremost, this new scheme will do absolutely nothing to
benefit the present, paying customers on Navajo. Navajo, we've been
told, is already overloaded, and there is no general student computing
on it (hence, none would be off-loaded to Portia). Recall that an
8700 is approximately five times as fast as a 780. Also recall that
a portion of the Navajo user community is investing fairly heavily
in workstation computing. As customers are driven away, rates rise,
resulting in a positive feedback loop and a cost center that generates
no income.
A second concern is whether the claimed savings would actually
materialize. Some questions that haven't been answered include the
difference in maintenance expenses on the 8700 vs. the 780, and
whether the "savings" from abandoning Sushi includes the reallocation
to Score of Truffle and the TOPS-20 software crew. Also, we were led
to believe that the offer from DEC was more-or-less a
"once-in-a-lifetime deal." Given that Navajo will eventually have to
be replaced, would we be throwing away a rare opportunity?
Another significant concern about the proposed deal is whether it will
provide adequate support for general student computing. There are at
least two questions that have to be addressed (some others have
already been mentioned). How reasonable is this offer? That is,
would the new LOTS 8800 actually be able to support the CS student
general computing in addition to all the work it will take on? LOTS
may not be taking into account that the claimed performance of the
8800 assumes that the dual-processor architecture is being used
effectively. The current DEC Ultrix software does not use both
processors of the dual-processor Vaxen, and dual processor support is
at least a year ahead. Hence, for the short term, the 8800 will not
provide significantly more compute power than the current Portia.
Also, LOTS can have no idea how well the current machine stands up to
a real workload, since its use has been sharply restricted. That is,
it has never been stressed. The second question is, even if the new
machine is capable of supporting CS student computing in addition to
the general and instructional computing to which LOTS is dedicated,
what guarantee do we have that this offer would not be withdrawn at
some future time, leaving CS students with no general computing
resources?
Ultimately, there is the question of the department's commitment to
student computing. Beyond support for general computing and
electronic communication (which is essential to conducting the
department's business), the department is encouraging more students to
seek fellowships and, hence, to rely on departmental support for
unfunded research. Abolishing departmental support for student
computing would send a very negative message to current and
prospective students.
joe
P.S. The issue of "better uses for gift funds" is a red herring.
CSD-CF should be deciding what the best alternative is among the
options available. Either the money is available, or it isn't.
-------
∂11-Aug-87 2216 REGES@Score.Stanford.EDU more thoughts
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Aug 87 22:16:06 PDT
Date: Tue 11 Aug 87 22:15:26-PDT
From: Stuart Reges <REGES@Score.Stanford.EDU>
Subject: more thoughts
To: "@facil.dis[p,doc]"@Sail.Stanford.EDU
cc: bscott@Score.Stanford.EDU, nilsson@Score.Stanford.EDU,
bureaucrats@Score.Stanford.EDU
Office: CS-TAC 22, 723-9798
Message-ID: <12325806158.10.REGES@Score.Stanford.EDU>
The department has been overspending its budget for a couple of years and
cannot continue to do so. If we need to spend $n on student computing next
year (as n approaches infinity), then we will certainly try to find $n to spend
on it, but that is getting harder and harder to do. So the funding issue is
certainly not a red herring.
Having read today's messages, I plan to offer a different suggestion at
tomorrow's meeting. I suggest that we go ahead with the plans to eliminate
SUSHI and buy a new VAX 8700. All students will get accounts on the new
machine, but we will ask students to do all coursework on Portia. If we can
somehow keep the coursework off of the new machine, I think we can manage to
provide our students all of the special things they want (e.g., lots of disk
space and access to newsgroups) at an affordable price. If Portia turns out to
be overcrowded and if we fail to convince LOTS to increase capacity, then we
can relax our usage policy and allow students to do coursework on the CSD
machine. In other words, I suggest *trying* to move coursework off of CSD
machines. If that experiment fails, we are all set up to move it back onto the
new CSD VAX. And in the meantime, the non-course usage of the new VAX by
students plus sponsored research migrating from Navajo should generate enough
revenue to allow CSD-CF to operate it without a deficit.
Looking forward to the discussion tomorrow.
--Stuart
-------
∂12-Aug-87 1016 TOM@Score.Stanford.EDU power shut-down dates
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Aug 87 10:16:38 PDT
Date: Wed 12 Aug 87 10:14:23-PDT
From: Thomas Dienstbier <TOM@Score.Stanford.EDU>
Subject: power shut-down dates
To: su-computers@Score.Stanford.EDU, staff@Score.Stanford.EDU,
faculty@Score.Stanford.EDU
Message-ID: <12325937039.9.TOM@Score.Stanford.EDU>
We now have the official times that power on campus will be shut off.
Saturday Sept. 12 0700-1200
Saturday Sept. 19 0700-1200
Sunday Sept. 20 0700-1200
All computers in Margaret Jacks hall will be down at the noted times above.
We may elect to keep selected machines/sytems down Sept. 19, 0700 thru
Sept. 20, 1200. We will probably have a better feeling for this after we
gain experience from the first power shut down on the 12th.
tom
-------
∂12-Aug-87 2318 TAJNAI@Score.Stanford.EDU Special Seminar, Friday, Aug. 14, 11 a.m., CIS
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Aug 87 23:17:58 PDT
Date: Wed 12 Aug 87 23:12:50-PDT
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Special Seminar, Friday, Aug. 14, 11 a.m., CIS
To: colloq@Score.Stanford.EDU, cis@Sierra.Stanford.EDU,
csl-everyone@Sierra.Stanford.EDU, Faculty@Score.Stanford.EDU
Message-ID: <12326078753.15.TAJNAI@Score.Stanford.EDU>
Friday, 11 a.m., August 14, CIS main conference room
Dr. Satoshi Goto, Manager System Research Laboratory, NEC
Dr. Goto, who is in charge of VLSI CAD and AI applications at NEC,
will speak on "A New Algorithm for VLSI Layout Verification and
Results of Computational Experiments."
Dr. Goto will chair a session at VLSI '87 to be held in Vancouver.
His visit is sponsored by the Computer Forum.
-------
∂13-Aug-87 2028 TAJNAI@score.stanford.edu TG for a Million Party
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 Aug 87 20:28:07 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Thu, 13 Aug 87 19:42:44 PDT
Date: Thu 13 Aug 87 15:46:22-PDT
From: Carolyn Tajnai <TAJNAI@score.stanford.edu>
Subject: TG for a Million Party
To: csd-list@score.stanford.edu, csl-everyone@sierra.stanford.edu
Message-Id: <12326259620.49.TAJNAI@Score.Stanford.EDU>
The Forum is hosting a Thank God for million dollars party
Friday, Aug. 14, 4:00 p.m., ERL patio.
Hope you can come and share in our celebration.
-------
∂14-Aug-87 0803 @HAL.CAD.MCC.COM:Loeffler@MCC.COM Windows Subcommittee
Received: from [128.62.1.126] by SAIL.STANFORD.EDU with TCP; 14 Aug 87 08:00:52 PDT
Date: Fri, 14 Aug 87 09:42 CDT
From: David D. Loeffler <Loeffler@MCC.COM>
Subject: Windows Subcommittee
To: X3j13@sail.stanford.edu
cc: Loeffler@MCC.COM
Message-ID: <870814094226.6.LOEFFLER@HAL.CAD.MCC.COM>
Reply-To: Loeffler@MCC.COM
Postal-address: MCC, 3500 West Balcones Center Dr., Austin, TX 78759
Business-phone: (512) 338-3666
What is the current status of the windows committee? I have two people
here at MCC that would like to participate.
-- David D. Loeffler
∂17-Aug-87 1217 @Sushi.Stanford.EDU:jan%ruuinfvax.uucp@forsythe.stanford.edu Copies of proceedings of 2nd Int. Workshop on Distributed Algorithms
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Aug 87 12:16:59 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Mon 17 Aug 87 12:03:59-PDT
Received: by lindy.stanford.edu; Mon, 17 Aug 87 12:05:10 PDT
Resent-From: jan%ruuinfvax.uucp@forsythe.stanford.edu
From: jan%ruuinfvax.uucp@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Mon, 17 Aug 87 12:04:06 PDT
Date: Sat, 15 Aug 87 11:18:05 +0200
Subject: Copies of proceedings of 2nd Int. Workshop on Distributed Algorithms
Message-Id: <C089.THEORYNT@ibm.com>
Resent-Date: 17 Aug 1987 15:04:20-EDT (Monday)
Resent-Sender: THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Resent-To: aflb.tn@sushi.stanford.edu
Apparently-To: aflb.tn@SUSHI.STANFORD.EDU
There are a number of copies left of the working proceedings of the 2nd
Int. Workshop on Distributed Algorithms, held July 8-10 1987 in Amsterdam,
containing draft versions of the 29 papers presented. If you are interested
in obtaining a copy, you can order one by sending a check of $15 to
Prof. Jan van Leeuwen or Geraldine Leebeek, Dept. of Computer Science,
University of Utrecht, P.O.Box 80.012, 3508 TA Utrecht, the Netherlands,
tel. +31-30-531454, email: ..!mcvax!ruuinfvax!gerald
∂18-Aug-87 1148 NILSSON@Score.Stanford.EDU kudos for Chuck Bigelow
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 18 Aug 87 11:48:25 PDT
Date: Tue 18 Aug 87 11:43:10-PDT
From: Nils Nilsson <NILSSON@Score.Stanford.EDU>
Subject: kudos for Chuck Bigelow
To: faculty@Score.Stanford.EDU
Message-ID: <12327526067.25.NILSSON@Score.Stanford.EDU>
Don Knuth informs me that Chuck Bigelow will be receiving the Goudy Award
from Rochester Institute of Technology. Knuth says that "this is the most
prestigious school for printing in America; for at least 70 years it has
produced the best printers... and Goudy was America's foremost type
designer... so I imagine the Goudy Award is for Chuck's field something lke
the Turing Award is for mine."
Congratulations Chuck!
-Nils
-------
∂18-Aug-87 1237 JSW Gang-of-Four is sick
To: Alliant-Users@SAIL.STANFORD.EDU
The Alliant started having problems last night, apparently with
its IP cache. It will probably stay down until at least tomorrow.
∂18-Aug-87 1313 @Score.Stanford.EDU:FEIGENBAUM@SUMEX-AIM.STANFORD.EDU Japan, anyone?
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 18 Aug 87 13:13:21 PDT
Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Tue 18 Aug 87 13:09:06-PDT
Date: Tue, 18 Aug 87 13:12:08 PDT
From: Edward Feigenbaum <FEIGENBAUM@SUMEX-AIM.STANFORD.EDU>
Subject: Japan, anyone?
To: faculty@SCORE.STANFORD.EDU
Message-ID: <12327542261.43.FEIGENBAUM@SUMEX-AIM.STANFORD.EDU>
Four Japanese companies have endowed Chairs at the prestigious University of
Tokyo to fund visits of distinguished foreign scientists in computer science,
information science, and telecommunications. The length of the stays are
one year, except longer (two years) or shorter (six months) are possible by
negotiation. The announcement is vague about money, but my reading of it
is that the stipend plus various allowances will be handsome (which in Tokyo
means adequate). If anyone is interested, let me know and I will send along
the material I have.
Ed
-------
∂18-Aug-87 1419 NILSSON@Score.Stanford.EDU [reid@decwrl.DEC.COM (Brian Reid): Re: kudos for Chuck Bigelow]
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 18 Aug 87 14:19:09 PDT
Date: Tue 18 Aug 87 14:14:29-PDT
From: Nils Nilsson <NILSSON@Score.Stanford.EDU>
Subject: [reid@decwrl.DEC.COM (Brian Reid): Re: kudos for Chuck Bigelow]
To: faculty@Score.Stanford.EDU
Message-ID: <12327553612.25.NILSSON@Score.Stanford.EDU>
fyi
---------------
Return-Path: <reid@decwrl.DEC.COM>
Received: from sonora.dec.com by SCORE.STANFORD.EDU with TCP; Tue 18 Aug 87 12:34:09-PDT
Received: from woodpecker.dec.com by sonora.dec.com (5.54.4/4.7.34)
id AA23800; Tue, 18 Aug 87 12:37:12 PDT
Received: by woodpecker.DEC.COM (1.2/4.7.34)
id AA00575; Tue, 18 Aug 87 12:34:53 pdt
From: reid@decwrl.DEC.COM (Brian Reid)
Message-Id: <8708181934.AA00575@woodpecker.DEC.COM>
Date: 18 Aug 1987 1234-PDT (Tuesday)
To: Nils Nilsson <NILSSON@score.stanford.edu>
Subject: Re: kudos for Chuck Bigelow
In-Reply-To: Nils Nilsson <NILSSON@score.stanford.edu> /
Tue 18 Aug 87 11:43:10-PDT.
<12327526067.25.NILSSON@Score.Stanford.EDU>
Another congratulation for Chuck Bigelow is also in order. If you have
seen the September issue of Scientific American, you will probably have
noticed that it has been redesigned, with new type faces and new
layouts. This redesign was done by Chuck Bigelow and Kris Holmes, and
the new type faces are Lucida, also designed by Bigelow and Holmes.
-------
∂18-Aug-87 1518 TOM@Score.Stanford.EDU imagen/maple
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 18 Aug 87 15:18:52 PDT
Date: Tue 18 Aug 87 15:14:42-PDT
From: Thomas Dienstbier <TOM@Score.Stanford.EDU>
Subject: imagen/maple
To: staff@Score.Stanford.EDU, faculty@Score.Stanford.EDU
Message-ID: <12327564574.21.TOM@Score.Stanford.EDU>
After the arrival of the two fuser rollers on maple, we should have it
operational within a few hours. Thank you for your patience in dealing
with this problem.
tom
-------
∂18-Aug-87 1652 GILBERTSON@Score.Stanford.EDU 87-88 Parking Permit - Dept Delivery
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 18 Aug 87 16:49:26 PDT
Date: Tue 18 Aug 87 16:31:29-PDT
From: Edith Gilbertson <GILBERTSON@Score.Stanford.EDU>
Subject: 87-88 Parking Permit - Dept Delivery
To: Faculty@Score.Stanford.EDU, RAs@Score.Stanford.EDU,
Staff@Score.Stanford.EDU, Visitors@Score.Stanford.EDU
cc: Gilbertson@Score.Stanford.EDU
Message-ID: <12327578552.14.GILBERTSON@Score.Stanford.EDU>
Dear CS Dept Automobile Drivers,
I have been designated to be your Stanford Parking Permit contact person.
Please bring your application to me by August 27 - all completed and ready
to go.
Remember to include your check, or fill out the Payroll Deduction section on
the back side of the green Vehicle Parking Registration form.
You may bring it to my office in Margaret Jacks Hall - Room 206 - from
8-12 or 1-5. I will notify you when your shiny new parking permit arrives
in the CS Dept, and you may drop by to pick it up.
See you before August 27,
-Edith
3-1520
-------
∂18-Aug-87 2006 SCHAFFER@Sushi.Stanford.EDU Next AFLB
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 18 Aug 87 20:06:18 PDT
Date: Tue 18 Aug 87 20:03:16-PDT
From: Alejandro Schaffer <SCHAFFER@Sushi.Stanford.EDU>
Subject: Next AFLB
To: aflb.all@Sushi.Stanford.EDU
Message-ID: <12327617106.8.SCHAFFER@Sushi.Stanford.EDU>
The next regular AFLB will be on 27 August. A title and abstract follow.
27-August-1987: Ken Clarkson (AT & T Bell Laboratories)
Probabilistic Methods in Combinatorial Geometry
Sometimes a combinatorial argument is best expressed in terms of
probabilities. I'll discuss an instance of this in discrete geometry,
a proof of a new bound for semi-space partitions of point sets.
For a set S \subset E↑d with n points in general position, let
T \subset S contain d points. If the hyperplane defined by T
bounds an open halfspace containing no more than k points of S,
then T is a (<=k)-facet of S. For example, a (<=0)-facet
of a set of points in the plane defines an edge of the convex hull of
S, and in general, an ordinary facet of the convex hull of S
corresponds to a (<=0)-facet of S. The Upper Bound Theorem
of convex polytope theory says that the number of (<=0)-facets of S
is O(n↑s), where s is the integer part of d/2. In this talk,
I'll use a simple probabilistic argument to show that the number of
(<=k)-facets of S is no more than O(n↑s k↑{d-s}). Similar
ideas can be used to show that this bound is tight, and to derive
bounds for the expected number of (<=k)-facets of random points.
This result has applications to algorithm for halfspace range reporting.
If time permits, I'll discuss a probabilistic argument that the total
number of edges of a set of m cells in an arrangement of n lines
in the plane is bounded by O(n↑{2/3+ epsilon} m↑{2/3} + nlog m) for
any fixed epsilon > 0.
***** Time and place: August 27, 12:30pm in MJ352 (Bldg. 460) *****
-------
∂19-Aug-87 1006 TAJNAI@Score.Stanford.EDU photos for brochure
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 19 Aug 87 10:06:05 PDT
Date: Wed 19 Aug 87 10:01:33-PDT
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: photos for brochure
To: faculty@Score.Stanford.EDU
Message-ID: <12327769710.24.TAJNAI@Score.Stanford.EDU>
Nils wants me to schedule a photographer for photos for the brochure.
Please give me some windows when you'll be on campus next week.
Carolyn
-------
∂19-Aug-87 1516 TOM@Score.Stanford.EDU [Thomas Dienstbier <TOM@Score.Stanford.EDU>: 87000 purchase/or not]
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 19 Aug 87 15:16:47 PDT
Date: Wed 19 Aug 87 15:13:39-PDT
From: Thomas Dienstbier <TOM@Score.Stanford.EDU>
Subject: [Thomas Dienstbier <TOM@Score.Stanford.EDU>: 87000 purchase/or not]
To: "@facil.dis[p,doc]"@Sail.Stanford.EDU
Message-ID: <12327826528.19.TOM@Score.Stanford.EDU>
Mail-From: TOM created at 19-Aug-87 14:27:53
Date: Wed 19 Aug 87 14:27:53-PDT
From: Thomas Dienstbier <TOM@Score.Stanford.EDU>
Subject: 87000 purchase/or not
To: "facil.dis[p,doc]]"@Sail.Stanford.EDU
cc: tom@Score.Stanford.EDU, ball@Score.Stanford.EDU, kolk@Score.Stanford.EDU
Message-ID: <12327818195.25.TOM@Score.Stanford.EDU>
I will be out of town next week, I probably won't have any input
to give at the next facilities meeting. Since the discussion is one of
major concern to the department I would hope that the meeting be opened-
up to some of the research facility. Ullman, Cheriton, McCarthy,
Oliger, Binford to name just a few. My view is that whatever we select is not
probably the answer for future computer needs but that of a immediate stop-gap
solution. The 8700 as I view, would more-than-likely transform into a
very fast and large file server. I speculate the direction towards work
stations on every desk and large and fast file servers rather than
terminals and mainframes.
I do not speculate on affordabilty of this or who benefits
the most(students/research)but feel both are very important to Computer
Science.
tom
-------
-------
∂20-Aug-87 1515 SCHAFFER@Sushi.Stanford.EDU Special AFLB
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Aug 87 15:15:03 PDT
Date: Thu 20 Aug 87 15:09:08-PDT
From: Alejandro Schaffer <SCHAFFER@Sushi.Stanford.EDU>
Subject: Special AFLB
To: aflb.all@Sushi.Stanford.EDU, su-events@Sushi.Stanford.EDU,
csd@Sushi.Stanford.EDU
Message-ID: <12328087849.27.SCHAFFER@Sushi.Stanford.EDU>
There will be a special AFLB talk next Wednesday 26 August in
MJH352 at 12:30PM. The speaker will be Yossi Matias from Weizmann
Institute. He will speak on "Video Scrambling Techniques based on
Space-Filling Curves." I don't yet have an abstract.
-------
∂20-Aug-87 1622 LES Facilities Committee Meetings
To: Facil@SAIL.STANFORD.EDU, Nilsson@SCORE.STANFORD.EDU,
Ullman@SCORE.STANFORD.EDU, Reges@SCORE.STANFORD.EDU,
Oliger@SCORE.STANFORD.EDU
CC: BScott@SCORE.STANFORD.EDU
Another meeting of the Facilities Committee and other interested parties
on plans for Sushi, Navajo, and the possible new DEC 8700 will be held on
Wednesday, August 26 at 2:00pm in Jacks 352.
Minutes of Facilities Committee meeting on 8/12/87
Committee members who attended were Earnest, Ball, Dienstbier, Freeman,
Hitson, Pallas and Rindfleisch. Absent were Binford, Buchanan, Cheriton,
and Guibas. Other attendees were Kolkowitz and Reges.
Four alternative plans were discussed:
A. Trade in Sushi and Navajo on a new DEC 8700, which would become a
CSD-CF cost center supporting the populations of both machines.
B. Do A and, in addition, have students do coursework on the new
Portia (a new DEC 8800 recently acquired by AIR, formerly LOTS).
C. Move students to the new Portia, shut down Sushi and keep it in
reserve as a contingency.
D. Continue with things as they are.
A cancellable order exists for the DEC 8700 with a cancellation deadline
of 8/27 if we wish to follow either plan C or D.
Both A and B would involve slightly higher financial committments by CSD
than at present. Given that the department is already deficit spending,
there is some question about whether either of these alternatives is
affordable. There is even some question about whether D is affordable.
Alternative C would shift the burden of providing general student
computing support to AIR and would save the department a lot of money
(on the order of $100k per year), but involves risks that the student
computer support might not be adequate in some ways. Some of the funds
that would be freed by this plan could be used to ameliorate any problems
that might arise.
No consensus was reached on which plan should be followed, though students
and CSD-CF staff members generally seemed to favor "A" while bureaucrats
Earnest and Rindfleisch leaned toward "C."
It seems appropriate to gather more information about AIR access policies,
existing system load on Navajo, and the financial implications of the
alternative plans.
∂21-Aug-87 0618 @Sushi.Stanford.EDU:craig%computer-science.strathclyde.ac.uk@forsythe.stanford.edu Complexity of communicating processors
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 Aug 87 06:18:10 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Fri 21 Aug 87 06:13:10-PDT
Received: by lindy.stanford.edu; Fri, 21 Aug 87 06:14:34 PDT
Resent-From: craig%computer-science.strathclyde.ac.uk@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Fri, 21 Aug 87 06:13:16 PDT
Date: 19 Aug 87 14:16:57 GMT
From: craig%computer-science.strathclyde.ac.uk@forsythe.stanford.edu (Craig Renfrew)
Subject: Complexity of communicating processors
Message-Id: <C090.THEORYNT@ibm.com>
Resent-Date: 21 Aug 1987 09:13:11-EDT (Friday)
Resent-Sender: THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Resent-To: aflb.tn@sushi.stanford.edu
Apparently-To: aflb.tn@SUSHI.STANFORD.EDU
Most of the theory on computational complexity of parallel processing
assumes perfect communication between processing elements. Can anyone give
me pointers to the literature where the problems of inter-communication
are discussed or analysed ?
Craig
ARPA: craig%cs.strath.ac.uk@ucl-cs.arpa, craig@cs.strath.ac.uk
UUCP: craig@strath-cs.uucp, ...!seismo!mcvax!ukc!strath-cs!craig
JANET: craig@uk.ac.strath.cs
∂21-Aug-87 0937 TAJNAI@score.stanford.edu 2 Apple laserwriters stolen from ERL
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 Aug 87 09:37:36 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Fri, 21 Aug 87 09:29:50 PDT
Date: Fri 21 Aug 87 09:28:46-PDT
From: Carolyn Tajnai <TAJNAI@score.stanford.edu>
Subject: 2 Apple laserwriters stolen from ERL
To: csd.list@score.stanford.edu
Message-Id: <12328288032.14.TAJNAI@Score.Stanford.EDU>
Last night 2 Apple laserwriters were stolen from the student wing
of ERL. The room is non-secured. This is to alert everyone that
we must use caution in securing our equipment.
-------
∂21-Aug-87 1237 @Sushi.Stanford.EDU:steve%hubcap.clemson.edu@forsythe.stanford.edu Announcing expanded subject interest on "comp.hypercube"
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 Aug 87 12:36:55 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Fri 21 Aug 87 12:25:07-PDT
Received: by lindy.stanford.edu; Fri, 21 Aug 87 12:26:19 PDT
Resent-From: steve%hubcap.clemson.edu@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Fri, 21 Aug 87 12:24:48 PDT
Date: Fri, 21 Aug 87 15:07:03 edt
From: "Steve" Stevenson <steve%hubcap.clemson.edu@forsythe.stanford.edu>
Subject: Announcing expanded subject interest on "comp.hypercube"
Message-Id: <C092.THEORYNT@ibm.com>
Resent-Date: 21 Aug 1987 15:24:25-EDT (Friday)
Resent-Sender: THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Resent-To: aflb.tn@sushi.stanford.edu
Apparently-To: aflb.tn@SUSHI.STANFORD.EDU
Despite its name, the USENET news group "comp.hypercube" is interested in
all issues relating to parallel processing. We would like to expand the
readership of the news group and therefore we are solicitiing your
participation.
For those not on USENET, we expect shortly to have an ARPAnet gateway.
Among the topics of interest are
@ Complexity results.
@ Language issues - semantics.
@ Language issues - features to support various parallel architectures.
@ Bench mark results and comparisons.
@ Algorithms.
Any questions may be directed to me or to the following CSNET address:
dsteven@clemson
D. E. (call me Steve) Stevenson steve@hubcap.clemson.edu
Department of Computer Science, fpst@hubcap.clemson.edu
Clemson University, Clemson, SC 29634-1906 (803)656-5880.mabell
∂21-Aug-87 1246 @Sushi.Stanford.EDU:shebs%cs.utah.edu@forsythe.stanford.edu Clustering to Minimize Window Motion
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 Aug 87 12:46:07 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Fri 21 Aug 87 12:26:18-PDT
Received: by lindy.stanford.edu; Fri, 21 Aug 87 12:27:37 PDT
Resent-From: shebs%cs.utah.edu@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Fri, 21 Aug 87 12:26:12 PDT
Date: 21 Aug 87 16:27:47 GMT
From: shebs%cs.utah.edu@forsythe.stanford.edu (Stanley Shebs)
Subject: Clustering to Minimize Window Motion
Message-Id: <C091.THEORYNT@ibm.com>
Resent-Date: 21 Aug 1987 15:26:32-EDT (Friday)
Resent-Sender: THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Resent-To: aflb.tn@sushi.stanford.edu
Apparently-To: aflb.tn@SUSHI.STANFORD.EDU
Does anybody know of any good algorithms to cluster nearby points to
minimize the moving of a window over those points? In case that wasn't
clear, suppose I have a set of points randomly scattered over the plane,
and a rectangular window of some fixed size, and I want to get each point
visible inside the window at least once. I move the window some number of
times, and that number will of course be between 0 (if all the points fit in
one view) and the number of points (if they're all far apart). Moving the
window is expensive, so what I want is an algorithm to determine the smallest
set of window positions that covers all the points. The algorithm should
probably be quadratic in the number of points or better - optimality is
less important. Algorithms, references and reductions to similar problems
are all welcome...
stan shebs
shebs@cs.utah.edu
(Incidentally, this problem arose in connection with my recently posted
game "xconq", where the points are playing pieces and the window is an
X window, so a good algorithm will likely show up in the next release!)
∂21-Aug-87 1337 TAJNAI@Score.Stanford.EDU New Forum Membership Status
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 Aug 87 13:37:17 PDT
Date: Fri 21 Aug 87 13:32:22-PDT
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: New Forum Membership Status
To: faculty@Score.Stanford.EDU
Message-ID: <12328332378.14.TAJNAI@Score.Stanford.EDU>
The Forum Steering Committee, Profs. Hennessy and Nilsson have
approved a special membership category.
Companies that are classified as small business companies, i.e.,
under 500 employees, can join the Forum at one-third discount
and receive one-third fewer benefits.
Membership cost: $9,000 per year
only 2 representatives for the company will be invited to the annual meeting.
only 2 microfiche copies of research reports and resume books will be sent.
Finder's fee of $1500 per year for first three years of membership - unchanged.
Faculty liaison fee of $2000/year for local companies and $2500 for those
requiring travel - unchanged.
If you know of a company that fits this category, and you think they will
be interested in Forum membership, send me the information and I'll
follow up.
Carolyn
-------
∂22-Aug-87 1750 PALLAS@Sushi.Stanford.EDU Re: Facilities Committee Meetings
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 22 Aug 87 17:50:34 PDT
Date: Sat 22 Aug 87 17:49:00-PDT
From: Joseph I. Pallas <PALLAS@Sushi.Stanford.EDU>
Subject: Re: Facilities Committee Meetings
To: Facil@Sail.Stanford.EDU
cc: Nilsson@Score.Stanford.EDU, Reges@Score.Stanford.EDU
In-Reply-To: Message from "Les Earnest <LES@SAIL.STANFORD.EDU>" of Thu 20 Aug 87 16:22:00-PDT
Message-ID: <12328641239.15.PALLAS@Sushi.Stanford.EDU>
I'd like to present a summary of student views on the issue before the
facilities committee of purchasing a VAX 8700. The student opinions
that were expressed were almost entirely in favor of the VAX over the
counter-proposal to shift all unsponsored student computing to AIR.
Some of the comments addressed specific concerns about relying on AIR,
while others dealt with more general issues.
Briefly, students said:
+ Time-limited access to non-coursework student computing is unacceptable.
+ Non-CSD administration of student computing is likely to be unresponsive
to our needs.
+ Dependency on the largesse of AIR is dangerous.
+ The department definitely should be investing in up-to-date computing
facilities.
+ The department must recognize its obligation to support student computing.
All of these, I think, are sound arguments in favor of going ahead with the
VAX 8700 purchase.
Here in more detail are some of the specific concerns raised:
In the past, the LOTS facility has relied on login time restrictions
to deal with overload conditions. In the event that such restrictions
were applied to Portia, the machine would be effectively useless for
serious work (especially intensive thesis-type writing). Such
restrictions would also make the machine inconvenient for electronic
mail and bulletin board access. This approach to load control is of
special concern because several introductory (i.e., large) courses are
supposed to start using the machine this year. (Editor's note: even
furious manipulation of various claims for the expected performance of
the new Portia have failed to justify the conclusion that it will be
under-utilized by the expected coursework load.)
Another concern expressed was that, even if the computing resources
provided by AIR were adequate, there is no guarantee that the service
provided would be. In fact, several students who have interacted with
the Portia administration in the past year as TAs said that the
quality of the support supplied to coursework was fair to poor. Since
coursework would remain Portia's primary function, we would be foolish
to expect that CS student computing would receive any better support
(unless it were provided by CSD-CF at the department's expense).
Finally, one of the most important questions that has not been
answered is what would happen if AIR decided that CSD students were
taking up too much of Portia. Three possible answers are (1) we get
kicked off, leaving us with no student computing facilities, (2) we
start paying for the service (unlikely, given the way LOTS has been
run in the past), and (3) we start investing in additional hardware
for someone else's machine. Needless to say, the first would be
unacceptable, and the latter two unwise for the department.
Some of the students expressed more general concerns about the
department's approach to computing facilities. One complaint was that
neither of these proposals represents any real progress toward the
goal of providing the best possible resources. At best, we seem to be
discussing stop-gap measures intended to forestall disaster. Several
students have asked, ``Where are the workstations? Where is the
latest in technology?'' Some of them have even asked, ``If we're so
rich, why do we have such old equipment?''
I want to point out, in closing, that the proposal to terminate
department support for student computing has raised some very strong
emotions among the students. I regret, now, that there was really no
way to make it clear that the proposal did not represent any sort of
prevailing sentiment within the department. Some of the students with
fellowships were quite upset about the implications of providing no
departmental resources to fellowship holders doing unsponsored
research, especially in light of the department's efforts to encourage
students to pursue fellowships because they save the department money.
One remarked that his fellowship actually includes an amount for the
department designated for computing resources, and wondered how the
department could justify keeping that money. But the strongest
sentiment was that teaching is the department's job, and computer
science can't be taught without providing access to computing
resources. There is more to the CS graduate program at Stanford than
coursework and sponsored research, and the department must support
that something more if it wishes to retain its reputation as an
outstanding Computer Science department.
joe
-------
∂24-Aug-87 0913 hitson@pescadero.stanford.edu Re: Facilities Committee Meetings
Received: from PESCADERO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Aug 87 09:12:59 PDT
Received: from localhost by pescadero.stanford.edu with Sendmail; Mon, 24 Aug 87 09:05:35 pdt
To: Les Earnest <LES@sail.stanford.edu>
Cc: Facil@sail.stanford.edu, Nilsson@score.stanford.edu,
Ullman@score.stanford.edu, Reges@score.stanford.edu,
Oliger@score.stanford.edu
Cc: BScott@score.stanford.edu, hitson@pescadero.stanford.edu
Subject: Re: Facilities Committee Meetings
In-Reply-To: Your message of 20 Aug 87 1622 PDT.
Date: 24 Aug 87 09:05:21 PDT (Mon)
From: Bruce L Hitson <hitson@pescadero.stanford.edu>
The minutes of the Facilities Committee Meeting on 8/12/87 contain some
important omissions, and as a result do not represent my impression of
what transpired. In particular:
1. As I understood it, everyone except Earnest (and possibly
Rindfleisch--though he was only present for the last 10-15 minutes of
the meeting and didn't hear all the arguments that were presented) were
generally in favor of Plan B, *not* Plan A. Everyone agreed that
course-related computing was something that AIR, not CSD should support.
2. The minutes as currently worded focus only on *cost* considerations.
However, the committee discussed *need* for a large portion of an hour.
Everyone except Earnest (and possibly Rindfleisch--again, absent for
much of this important discussion) was convinced that a new 8700 (or
similar--Plan A or B) is *needed* by the department (both sponsored
research and students). It was pointed out that the long-time
departmental principle, "...if we decide we need something, we will
find the money for it somewhere..." was still valid.
3. Earnest had originally suggested a savings of approximately
$100K per year for Plan C (relative to Plan B or A). Committee members
pointed out at least three important reasons why overall departmental
savings were likely to be significantly less than this: (1) savings of
decommissioning Sushi and Navajo were overestimated because some
hardware upgrades to these machines are not fully depreciated, (2)
decommissioning Sushi will not significantly decrease the
responsibilities (and thus cost) of Dec20 system maintainers--these
costs will have to be absorbed by Score rates of which a large
percentage is departmental use (thus not saving the department this
money--just transferring it to a different account), and (3) savings
due to having a standard supported operating system environment
(VAX/Ultrix) on the 8700 might significantly reduce system programmer
effort (and thus, cost). Thus, there is a good chance that Plan C will
save much less than originally thought. More details are needed before
accurate costs of each plan can be compared.
4. Serious questions were raised about the ability of the AIR 8800 to
support any more users than the 8650 it replaces for quite a while
(because it was claimed that DEC does not have Ultrix software yet that
can make good use of the second processor that provides most of the
*theoretical* speedup of the 8800 over the 8650). It was also noted
that CSD students might be left to fend for themselves among an AIR
community of students doing unknown but potentially very heavy
course-related work. More investigation is needed into this issue.
5. At the Facilities Committee Meeting of 5/26/87, the committee--
including many faculty that were not able to attend the meeting on
8/12--had reached (after much prior discussion) a consensus that the
VAX 8700 was a resource that the department *needed*. These reasons
were repeated and elaborated at the 8/12 meeting:
- Many people in the department want (and are willing to pay for)
general-purpose Unix cycles.
- Navajo is saturated, people are complaining, many users already have
left, and other users are threatening to leave due to poor service.
- Labrea is CPU bound--it cannot provide the Unix cycles that people
in the department want.
- Department administrative functions will eventually have to move
off SCORE (and Dec20s in general); a likely environment for the new
systems is Unix. The required development for this switch has
to happen somewhere; a new 8700 could fulfill this need.
- Users want standard, supported, Unix cycles, not variants that are
software incompatible (or "mostly-" compatible). It was for this
reason that we previously decided on a VAX 8700. This is
consistent with the longer range goal of making departmental
administrative functions available on a stable supported machine.
My personal feeling is that the *need* for the VAX 8700 has been amply
demonstrated both in previous meetings, and again at the 8/12 meeting.
Though it is good to keep costs as low as possible, it seems that this
issue has been thoroughly discussed, and that our previous decision was
a good one. The departmental budget should not be balanced at the
expense of facilities which the community wants and needs. We should
proceed with Plan B (the acquisition of the 8700 and decommissioning
Sushi and Navajo) and get the new 8700 installed as soon as possible.
Even if the current schedule is met, the new resources will not be
available before late November (and more likely, early 1988).
--- Bruce Hitson
∂25-Aug-87 1510 ullman@navajo.stanford.edu papers received
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 25 Aug 87 15:09:56 PDT
Received: by navajo.stanford.edu; Tue, 25 Aug 87 14:55:53 PDT
Date: Tue, 25 Aug 87 14:55:53 PDT
From: Jeff Ullman <ullman@navajo.stanford.edu>
Subject: papers received
To: nail@navajo.stanford.edu
"Sets and Negation in a Logic DB Languages (LDL)"
Beeri, Naqvi, Shmueli, and Tsur, MCC DB-375-86
A revised version of their PODS 87 paper.
N Minsky: "Law Governed Systems"
N. Minsky and D. Rozenshtein: "Law-Based approach to Object-oriented
Programming"
These reports, from Rutgers, talk about "laws", which define how
messages are passed among objects. Among other things, it offers
programmer control of inheritance in "multiple inheritance"
situations, where a class C can be a subclass of several independent
classes, with possibly-contradictory definitions of methods in each
class.
---jdu
∂25-Aug-87 1716 LIBRARY@Score.Stanford.EDU Math/CS Library Material Access for Sept.
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 25 Aug 87 17:16:00 PDT
Date: Tue 25 Aug 87 17:07:36-PDT
From: Math/Computer Science Library <LIBRARY@Score.Stanford.EDU>
Subject: Math/CS Library Material Access for Sept.
To: su-events@Score.Stanford.EDU, faculty@Score.Stanford.EDU
cc: cn.cir@Forsythe.Stanford.EDU, cn.ref@Forsythe.Stanford.EDU,
sci.dept: ;
Message-ID: <12329420136.9.LIBRARY@Score.Stanford.EDU>
The Math/CS Library will be involved with an asbestos encapsulation & re-
lamping project during the month of September. The project is scheduled to
begin on September 2nd with the preparation of the selected work area (section)
The actual asbestos & relamping work will be restricted to the weekends while
the library is closed. However, if that work is not completed, it will over-
flow into the following week.
Each sections' material could be unavailable for a period up to one week.
The library will be divided up into 4 sections as noted on the map (avail-
able at the library). Each will be encapsulated with a containment barrier
before it is worked upon and thus, the library material within that area will
be unavailable. The exception to this will be all the material which is usually
contained on the top shelves. These will be moved to some temporary shelves
which will be located in the area adjacent to the terrace.
Please use the following schedule to plan your September library use.
Material involved:
Beginning approx. Sept. 2nd
Section #1 - LC books QA402.5 - Z; all Dewey Decimal books; TR's 14,000's
through 276,000's.
----------------------------
Beginning approx. Sept. 9th
Section #2 - Beginning of LC books - QA402.4.
----------------------------
Beginning approx. Sept. 16th
Section #3 - Journal stacks area from "Linear Algebra through "Z"; includes the
reading area noted on the map (copies available at the library).
----------------------------
Beginning approx. Sept. 23rd
Section #4 - The "new journal reading room", reference collection, indexes and
abstracts, and the journal stacks from "A" through "Leningrad
Universitet".
-------
∂25-Aug-87 1801 SCHAFFER@Sushi.Stanford.EDU Next AFLB
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 25 Aug 87 18:00:55 PDT
Date: Tue 25 Aug 87 17:49:05-PDT
From: Alejandro Schaffer <SCHAFFER@Sushi.Stanford.EDU>
Subject: Next AFLB
To: aflb.all@Sushi.Stanford.EDU
Message-ID: <12329427687.21.SCHAFFER@Sushi.Stanford.EDU>
26-August-87: Yossi Matias (Weizmann Instute of Science)
A Video Scrambling Technique
Based on Space Filling Curves.
In this paper we propose a video scrambling technique
which scans a picture stored in a frame buffer along a
pseudo-random space filling curve. We describe several
efficient methods for generating cryptographically strong
curves, and show that they actually decrease the bandwidth
required to transmit the picture.
This work is in collaboration with Adi Shamir.
***** Time and place: August 26, 12:30pm in MJ352 (Bldg. 460) *****
27-August-1987: Ken Clarkson (AT & T Bell Laboratories)
Probabilistic Methods in Combinatorial Geometry
Sometimes a combinatorial argument is best expressed in terms of
probabilities. I'll discuss an instance of this in discrete geometry,
a proof of a new bound for semi-space partitions of point sets.
For a set S \subset E↑d with n points in general position, let
T \subset S contain d points. If the hyperplane defined by T
bounds an open halfspace containing no more than k points of S,
then T is a (<=k)-facet of S. For example, a (<=0)-facet
of a set of points in the plane defines an edge of the convex hull of
S, and in general, an ordinary facet of the convex hull of S
corresponds to a (<=0)-facet of S. The Upper Bound Theorem
of convex polytope theory says that the number of (<=0)-facets of S
is O(n↑s), where s is the integer part of d/2. In this talk,
I'll use a simple probabilistic argument to show that the number of
(<=k)-facets of S is no more than O(n↑s k↑{d-s}). Similar
ideas can be used to show that this bound is tight, and to derive
bounds for the expected number of (<=k)-facets of random points.
This result has applications to algorithm for halfspace range reporting.
If time permits, I'll discuss a probabilistic argument that the total
number of edges of a set of m cells in an arrangement of n lines
in the plane is bounded by O(n↑{2/3+ epsilon} m↑{2/3} + nlog m) for
any fixed epsilon > 0.
***** Time and place: August 27, 12:30pm in MJ352 (Bldg. 460) *****
-------
∂25-Aug-87 1816 TAJNAI@score.stanford.edu CSD t-shirts and Proceedings from Reunion/Symposium
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 25 Aug 87 18:15:57 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Tue, 25 Aug 87 17:52:50 PDT
Date: Tue 25 Aug 87 14:35:08-PDT
From: Carolyn Tajnai <TAJNAI@score.stanford.edu>
Subject: CSD t-shirts and Proceedings from Reunion/Symposium
To: csd.list@score.stanford.edu
Message-Id: <12329392381.34.TAJNAI@Score.Stanford.EDU>
We have CSD t-shirts and copies of the Proceedings from the
Reunion/Symposium. They can be purchased from the CSD receptionist.
t-shirt $8@; sizes are:
2 smalls
7 x-large
30 medium (approx.)
30 large (approx.)
Copies of the Proceedings, which originally sold for $20 are available
for $10.
Carolyn Tajnai
-------
∂25-Aug-87 2020 LES Facilities Committee Meeting
To: Facil@SAIL.STANFORD.EDU, Nilsson@SCORE.STANFORD.EDU,
Ullman@SCORE.STANFORD.EDU, Reges@SCORE.STANFORD.EDU
CC: BScott@SCORE.STANFORD.EDU
This is a reminder that the Facilities Committee meets on Wednesday,
August 26 at 2:00pm in Jacks 352. It will be final decision day for
proceeding or not with the order for a new DEC 8700.
A hard copy analysis of the year-by-year incremental cost of buying an
8700 and a review of recent usage trends on Navajo, Sail, and Score that
Jim Ball put together is being put in local (Jacks Hall) mailboxes. There
will be more copies at the meeting.
As a possible way of generating enough business to support a new machine,
I have looked into shutting down SAIL. It appears that this could not be
done before about two years from now without causing serious problems for
some of the users.
It is clear from Bruce Hitson's Monday message that I am a money-grubbing
bureaucrat whose only goal is to distort truth, rob graduate students of
their birthright, and pervert the American way. Accepting all that, I
still have a few more remarks.
Mr. Hitson reports:
> 1. As I understood it, everyone except Earnest (and possibly
> Rindfleisch--though he was only present for the last 10-15 minutes of
> the meeting and didn't hear all the arguments that were presented) were
> generally in favor of Plan B, *not* Plan A.
I readily acknowledge that I neglected to report Stuart Reges's articulate
support of Plan B, but am amazed at Mr. Hitson's insight in knowing
everyone's position, given that we did not take a poll. He is probably
right about the student's views, given that the only change in going from
A to B is the addition of another "free" computer. From the viewpoint of
us money-grubbing bureaucrats, however, there is almost no defference
between A and B, given that that they both require the same overall
financial commitment from the department.
Mr. Hitson also says:
> 3. Earnest had originally suggested a savings of approximately
> $100K per year for Plan C (relative to Plan B or A). Committee members
> pointed out at least three important reasons why overall departmental
> savings were likely to be significantly less than this: (1) savings of
> decommissioning Sushi and Navajo were overestimated because some
> hardware upgrades to these machines are not fully depreciated, . . .
Perhaps Mr. Hitson has forgotten the name of the committee member who
brought up this killing "refutation" of Earnest's analysis. Hint: he
happens to be a money-grubbing bureaucrat.
> (2) decommissioning Sushi will not significantly decrease the
> responsibilities (and thus cost) of Dec20 system maintainers--these
> costs will have to be absorbed by Score rates of which a large
> percentage is departmental use (thus not saving the department this
> money--just transferring it to a different account), . . .
I am puzzled by this argument. Does he want us to keep Sushi going _and_
buy a DEC 8700?
> and (3) savings due to having a standard supported operating system
> environment (VAX/Ultrix) on the 8700 might significantly reduce system
> programmer effort (and thus, cost). Thus, there is a good chance that
> Plan C will save much less than originally thought.
Puzzled again. There seems to be no barrier to putting Ultrix on Navajo
in addition to Portia.
The central issue in all of this is revealed in the following assertion
by Mr. Hitson:
> - Many people in the department want (and are willing to pay for)
> general-purpose Unix cycles.
Unfortunately, he does not reveal who these moneyed buyers are. If we
can identify them, I will strongly support the purchase of a new machine
now. If not, I prefer to wait until we can figure out how to pay for it.
Still another stunning remark is that:
> - Navajo is saturated, people are complaining, many users already have
> left, and other users are threatening to leave due to poor service.
I am quite interested in who all these people are. From available
evidence, they do not exist. There are names for this kind of analysis.
I will settle for "hot air."
Suppose that a case _could_ be made that Navajo is or will soon become
overloaded. Immediately buying a shiney new 8700 would not be the only
solution. Another option would be to reactivate one of our several VAXen
as a service center. The attached message from Jim Ball reviews the
effect on net cost of one such option.
I invite refutations of any of the points that I have discussed, but
please, folks, in addition to the rhetorical hand-wringing, let's talk
about financial reality.
Les Earnest
∂25-Aug-87 1056 BALL@Score.Stanford.EDU Sushi shutdown Carmel rebirth
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 25 Aug 87 10:56:15 PDT
Date: Tue 25 Aug 87 10:49:05-PDT
From: James E. Ball <BALL@Score.Stanford.EDU>
Subject: Sushi shutdown Carmel rebirth
To: LES@Sail.Stanford.EDU
Message-ID: <12329351229.24.BALL@Score.Stanford.EDU>
Sushi vs Carmel
In reviewing the potential savings associated with turning off Sushi
and moving students to the AIR facility the following calculations
were performed.
Column 1 represents the current (1987) CSD-CF expenses associated with
the operation of Sushi. Column 2 assumes a shutdown of Sushi and transfer
of student computing to the DEC 8800 at AIR (LOTS). I will admit that
the potential savings are merely assumptions based on previouse budgets.
Colummn 3 represents the cost of running Carmel (DEC11/750) to assist in
providing additional UNIX cycles that may be required. Columnn 4 is the
net savings and column 5 the new CSD-CF expense for providing service
on Carmel rather than Sushi.
The resulting expense level of $59,739 per year represents a savings to
CSD-CF of $42,117 per year. The saving to the department of approximately
$100,000 per year would have to be reduced by the fact that there would be
a residual expense level of $59,739 which would have to be distributed
among the user community.
1 2 3 4 5
8/25/87
Sushi 87 Est.Savings Carmel cost Net Savings New CSD-CF
Salaries Sushi off turn on expense
Sys Prog 16288 0 0 0 16288
Tech 2678 0 0 0 2678
R&D/Eng 6125 6125 1000 5125 1000
Mgmt 7500 0 0 0 7500
Students 4320 2160 2160 0 4320
Benefits 9117 2046 781 1266 7851
Hardware 8125 8125 1000 7125 1000
Software 4000 4000 0 4000 0
Bldg/Wh/E 198 0 0 0 198
Trvl/Schls 1800 1800 200 1600 200
Expend 14625 14625 2000 12625 2000
Telecom 3600 3600 300 3300 300
Air Cond 841 0 0 0 841
Subtotal 79217 42481 7441 35041 44176
Com&Admin 10846 0 0 0 10846
Network 3600 3600 360 3240 360
Deprec 12728 3836 0 3836 8892
Carryover -4535 0 0 0 -4535
Subtotal 22639 7436 360 7076 15563
Grand Total 101856 49917 7801 42117 59739
-------
∂25-Aug-87 2032 REGES@Score.Stanford.EDU a small matter of $20K
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 25 Aug 87 20:32:46 PDT
Date: Tue 25 Aug 87 20:25:36-PDT
From: Stuart Reges <REGES@Score.Stanford.EDU>
Subject: a small matter of $20K
To: facil@Sail.Stanford.EDU
cc: nilsson@Score.Stanford.EDU
Office: CS-TAC 22, 723-9798
Message-ID: <12329456181.10.REGES@Score.Stanford.EDU>
Last week Les was asking me about new sources of revenue for CSD-CF machines.
I failed to mention one small but not insignificant source of money. The
Provost gave us $20K last year ($25K this year) for undergrad computing to be
done outside of LOTS. This money is part of our base-budget, which means we
will get it every year. I believe that we have asked for more like $35K or
$40K starting next year. Some of that money goes to run clusters, but most
could be spent on accounts on the new VAX 8700. When I mentioned the
possibility of putting undergrads on SUSHI, the grad students screamed loudly
enough that I didn't pursue it. So last year's $20K couldn't be spent on
SUSHI, but future money could be spent on a new machine if it is less crowded
than SUSHI.
-------
∂26-Aug-87 0917 @WARBUCKS.AI.SRI.COM,@malibu:olender@malibu.ai.sri.com PLANLUNCH / MONDAY AUGUST 31, 1987.
Received: from WARBUCKS.AI.SRI.COM by SAIL.STANFORD.EDU with TCP; 26 Aug 87 09:17:50 PDT
Received: from malibu by WARBUCKS.AI.SRI.COM via SMTP with TCP; Wed,
26 Aug 87 09:11:56-PDT
Received: by malibu (3.2/4.16) id AA00824 for planlunch@sri-warbucks;
Wed, 26 Aug 87 09:11:03 PDT
Date: Wed, 26 Aug 87 09:11:03 PDT
From: Margaret Olender <olender@malibu.ai.sri.com>
Message-Id: <8708261611.AA00824@malibu>
To: planlunch@sri-warbucks
Subject: PLANLUNCH / MONDAY AUGUST 31, 1987.
VISITORS: Please arrive 5 minutes early so that you can be escorted
up from the E-building receptionist's desk. Thanks!
11:00 AM, MONDAY, AUGUST 31, 1987
SRI INTERNATIONAL, BUILDING E, ROOM EJ228
HIGHER-ORDER LOGIC PROGRAMMING
Gopalan Nadathur
Duke University
In this work, the issue of introducing higher-order features into the
paradigm of logic programming is addressed. Towards this end, a
non-extensional form of higher-order logic that is based on Church's
simple theory of types has been used to describe a generalization to the
definite clauses of first-order logic. This generalization may be
categorised broadly as the one obtained by replacing first-order terms
by the terms of a typed lambda-calculus and by providing for
quantification over predicate and function variables. It is shown that
these formulas provide the basis for a logic programming language in the
sense that (a) they can be used together with a notion of a proof in the
higher-order logic to provide an abstract description of computation,
and (b) a theorem-proving procedure that provides the basis for an
interpreter can be described by appropriately generalizing the
well-known SLD-resolution procedure for first-order definite clauses.
Based on these results, a higher-order logic programming language called
lambda-Prolog has been developed.
During this talk, I shall describe the higher-order extension to
definite clauses, and outline their proof-theoretic properties that
enable us to accord them a computational interpretation. I shall also
illustrate how the use of the terms of a (typed) lambda-calculus as data
structures provides a source of richness to the logic programming
paradigm.
∂26-Aug-87 0948 @WARBUCKS.AI.SRI.COM,@malibu:olender@malibu.ai.sri.com PLANLUNCH / MONDAY AUGUST 31, 1987.
Received: from WARBUCKS.AI.SRI.COM by SAIL.STANFORD.EDU with TCP; 26 Aug 87 09:48:25 PDT
Received: from malibu by WARBUCKS.AI.SRI.COM via SMTP with TCP; Wed,
26 Aug 87 09:26:27-PDT
Received: by malibu (3.2/4.16) id AA00859 for planlunch@sri-warbucks;
Wed, 26 Aug 87 09:25:41 PDT
Date: Wed, 26 Aug 87 09:25:41 PDT
From: Margaret Olender <olender@malibu.ai.sri.com>
Message-Id: <8708261625.AA00859@malibu>
To: planlunch@sri-warbucks
Subject: PLANLUNCH / MONDAY AUGUST 31, 1987.
VISITORS: Please arrive 5 minutes early so that you can be escorted
up from the E-building receptionist's desk. Thanks!
11:00 AM, MONDAY, AUGUST 31, 1987
SRI INTERNATIONAL, BUILDING E, ROOM EJ228
HIGHER-ORDER LOGIC PROGRAMMING
Gopalan Nadathur
Duke University
In this work, the issue of introducing higher-order features into the
paradigm of logic programming is addressed. Towards this end, a
non-extensional form of higher-order logic that is based on Church's
simple theory of types has been used to describe a generalization to the
definite clauses of first-order logic. This generalization may be
categorised broadly as the one obtained by replacing first-order terms
by the terms of a typed lambda-calculus and by providing for
quantification over predicate and function variables. It is shown that
these formulas provide the basis for a logic programming language in the
sense that (a) they can be used together with a notion of a proof in the
higher-order logic to provide an abstract description of computation,
and (b) a theorem-proving procedure that provides the basis for an
interpreter can be described by appropriately generalizing the
well-known SLD-resolution procedure for first-order definite clauses.
Based on these results, a higher-order logic programming language called
lambda-Prolog has been developed.
During this talk, I shall describe the higher-order extension to
definite clauses, and outline their proof-theoretic properties that
enable us to accord them a computational interpretation. I shall also
illustrate how the use of the terms of a (typed) lambda-calculus as data
structures provides a source of richness to the logic programming
paradigm.
∂26-Aug-87 1206 hitson@gregorio.stanford.edu Re: Facilities Committee Meeting
Received: from GREGORIO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 26 Aug 87 12:06:44 PDT
Received: by gregorio.stanford.edu; Wed, 26 Aug 87 12:06:19 PDT
Date: 26 Aug 1987 1206-PDT (Wednesday)
From: Bruce Hitson <hitson@gregorio.stanford.edu>
To: les@sail.Stanford.EDU
Cc: facil@sail.Stanford.EDU, nilsson@score.Stanford.EDU,
ullman@score.Stanford.EDU, reges@score.Stanford.EDU
Cc: bscott@score.Stanford.EDU, hitson@gregorio.stanford.edu
Subject: Re: Facilities Committee Meeting
Les,
Thank you for your comments on my recent note to facilities regarding
proposed changes in computing resources in CSD. My goals were to point
out (unintentional) omissions in the minutes, and to elaborate on
discussion that I think deserves more attention, particularly by the
members of the committee who were not able to attend the recent
meeting. I will be happy to discuss the specific points you raised at
our meeting this afternoon; there are many important questions that
remain unanswered.
One of my roles on the Facilities Committee is as a representative of
student views. I hope it is clear from the summary of student opinion
that Joe Pallas has previously sent to this list that students are very
nervous about losing computing resources. Another of my roles is as a
member of the department, trying to work to improve the overall
situation and not just maintain the status quo (or, as in the case of
the recently proposed Plans involving cancellation of the 8700 order, a
net decrease in computing resources). It is with these roles in mind
that I will continue to ask tough questions about the rationale for and
long-range effects of proposed plans. Of course, the same tough
questions should be asked about cost. By working together and
answering *all* questions and concerns, I am confident that we can
reach a decision that is both wise and that everyone can live with.
-- Bruce Hitson
∂27-Aug-87 1650 TAJNAI@Score.Stanford.EDU Sunrise Club Important Announcement
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 27 Aug 87 16:50:21 PDT
Date: Thu 27 Aug 87 16:41:52-PDT
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Sunrise Club Important Announcement
To: faculty@Score.Stanford.EDU
Message-ID: <12329939740.17.TAJNAI@Score.Stanford.EDU>
TO: Sunrise Members
Computer Science professors
Electrical Engineering professors
FROM: Joanne Chequer (assistant to Dwain Fullerton)
DATE: August 27, 1987
The Sunrise meeting schedule has been changed. Please note that this
new schedule replaces a previous one sent to you this past June.
Tuesday, September 22, 1987
Monday, November 16, 1987
Tuesday, January 26,1988
Tuesday, March 22, 1988
Tuesday, May 24, 1988
All meetings will be at Tresidder, Oak Lounge West 7:30 - 9 a.m.
Professor M.R. Beasley will be giving a special presentation on
"New Advances in Superconductivity" on September 22.
RSVP Tajnai@score (as soon as possible please)
-------
∂31-Aug-87 0924 @WARBUCKS.AI.SRI.COM,@BISHOP.AI.SRI.COM:Pollack@AI.SRI.COM PLANLUNCH reminder
Received: from WARBUCKS.AI.SRI.COM by SAIL.STANFORD.EDU with TCP; 31 Aug 87 09:24:35 PDT
Received: from BISHOP.AI.SRI.COM by WARBUCKS.AI.SRI.COM via SMTP with
TCP; Mon, 31 Aug 87 09:18:40-PDT
Date: Mon, 31 Aug 87 09:17 PDT
From: Martha Pollack <Pollack@AI.SRI.COM>
Subject: PLANLUNCH reminder
To: planlunch@AI.SRI.COM, csl@AI.SRI.COM
Fcc: BISHOP:>pollack>mail>mail.out
Message-ID: <870831091734.3.POLLACK@BISHOP.AI.SRI.COM>
VISITORS: Please arrive 5 minutes early so that you can be escorted
up from the E-building receptionist's desk. Thanks!
***TODAY***
11:00 AM, MONDAY, AUGUST 31, 1987
SRI INTERNATIONAL, BUILDING E, ROOM EJ228
HIGHER-ORDER LOGIC PROGRAMMING
Gopalan Nadathur
Duke University
In this work, the issue of introducing higher-order features into the
paradigm of logic programming is addressed. Towards this end, a
non-extensional form of higher-order logic that is based on Church's
simple theory of types has been used to describe a generalization to the
definite clauses of first-order logic. This generalization may be
categorised broadly as the one obtained by replacing first-order terms
by the terms of a typed lambda-calculus and by providing for
quantification over predicate and function variables. It is shown that
these formulas provide the basis for a logic programming language in the
sense that (a) they can be used together with a notion of a proof in the
higher-order logic to provide an abstract description of computation,
and (b) a theorem-proving procedure that provides the basis for an
interpreter can be described by appropriately generalizing the
well-known SLD-resolution procedure for first-order definite clauses.
Based on these results, a higher-order logic programming language called
lambda-Prolog has been developed.
During this talk, I shall describe the higher-order extension to
definite clauses, and outline their proof-theoretic properties that
enable us to accord them a computational interpretation. I shall also
illustrate how the use of the terms of a (typed) lambda-calculus as data
structures provides a source of richness to the logic programming
paradigm.
∂31-Aug-87 1031 @Sushi.Stanford.EDU:sadler%Buckner-EMH.arpa@forsythe.stanford.edu Rqst for help from readers
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 31 Aug 87 10:31:52 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Mon 31 Aug 87 09:35:43-PDT
Received: by lindy.stanford.edu; Mon, 31 Aug 87 07:03:04 PDT
Resent-From: sadler%Buckner-EMH.arpa@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Mon, 31 Aug 87 07:01:36 PDT
Date: 29 Aug 87 14:04:14 GMT
From: sadler@BUCKNER-EMH.ARPA
Subject: Rqst for help from readers
Message-Id: <C093.THEORYNT@ibm.com>
Resent-Date: 31 Aug 1987 09:53:11-EDT (Monday)
Resent-Sender: THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Resent-To: aflb.tn@sushi.stanford.edu
Apparently-To: aflb.tn@SUSHI.STANFORD.EDU
This may not be the right forum for this question but I need help so
badly I'll risk it anyway; I'm having trouble developing an algorithm that
will identify various unique combinations of objects.
The problem I have is probably just a simple matter of logic that, for
some reason, I can't work out. Although I can't explain exactly what my
application is, I can provide an analogous situation that illustrates the
concept I'm wrestling with.
Imagine this hypothectical situation:
Given 1) a club whose sole purpose for existence is to "meet and mingle".
2) there are 20 members (call this A).
3) the meeting place has 5 tables (call this B) numbered 1 to 5.
4) each table seats 4 (call this C).
5) the club will meet weekly for 12 weeks (call this D).
Problem: devise a method to arrange seating at each meeting such that, for
the entire 12 weeks, no two members sit at the same table twice. In other
words, each table would have four members but the mix of four would always
be unique.
What I want to do is develop an algorithm so that I can specify the
variables A, B, C, and D then sit back and let the computer take over and
provide a list of unique combinations (members) per node (table) per period
(week). The only language I speak is BASIC so I'm obviously not obsessed
with speed but any help or code you can provide will sure help.
It seems like I saw something like this years ago in a quantitative
analysis book but I can't find it now. Again, if you can just point me in
the right direction, it'll help.
My address is sadler@buckner-emh.arpa
Please feel free to write to me directly as I am not yet on this
mailing list.
∂31-Aug-87 1103 TAJNAI@Score.Stanford.EDU $25K from NTT - anyone claim it?
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 31 Aug 87 11:02:55 PDT
Date: Mon 31 Aug 87 10:02:00-PDT
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: $25K from NTT - anyone claim it?
To: faculty@Score.Stanford.EDU, staff@Score.Stanford.EDU
Message-ID: <12330915520.22.TAJNAI@Score.Stanford.EDU>
Cash management called. They received $25K from NTT. It doesn't
belong to the Forum, and I have no idea to whom it belongs. Let me
know if it is yours?
Carolyn
-------
∂01-Sep-87 1245 @Score.Stanford.EDU:SMC@SAIL.STANFORD.EDU Phone numbers for John McCarthy
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Sep 87 12:45:24 PDT
Received: from SAIL.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Tue 1 Sep 87 12:36:51-PDT
Date: 01 Sep 87 1241 PDT
From: Sarah McCarthy <SMC@SAIL.STANFORD.EDU>
Subject: Phone numbers for John McCarthy
To: faculty@SCORE.STANFORD.EDU
John will be at the Univ. of Texas, Austin, through Fall quarter. His phone
numbers are: Home (512) 328-1625 & Office (512) 741-9558
∂01-Sep-87 1554 @Score.Stanford.EDU:SMC@SAIL.STANFORD.EDU McCarthy Phone #s
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Sep 87 15:54:34 PDT
Received: from SAIL.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Tue 1 Sep 87 15:45:47-PDT
Date: 01 Sep 87 1551 PDT
From: Sarah McCarthy <SMC@SAIL.STANFORD.EDU>
Subject: McCarthy Phone #s
To: faculty@SCORE.STANFORD.EDU
John McCarthy's office phone number is (512) 471-9558, not (512) 741-9558
Sorry about that.
∂02-Sep-87 0945 EMMA@CSLI.Stanford.EDU CSLI Talk
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Sep 87 09:45:35 PDT
Date: Wed 2 Sep 87 08:41:56-PDT
From: Emma Pease <Emma@CSLI.Stanford.EDU>
Subject: CSLI Talk
To: friends@CSLI.Stanford.EDU
Tel: (415) 723-3561
Message-ID: <12331425233.19.EMMA@CSLI.Stanford.EDU>
CSLI TALK
"The CAP System and its Application to Programming"
Y. Takayama, Researcher at ICOT, Tokyo
2:15, September 8, 1987
Ventura Trailer Classroom
The CAP project at ICOT is overviewed in this talk. This is the
research and development project that aims to build a user friendly
environment for mathematical reasoning. The first version of the proof
checker system for reasoning in linear algebra is running on the PSI
machine that is a workstation also developed in ICOT.
As a subproject, the research on the programming system based on
constructive logic was started about one year ago. This system is
along the same lines as the Nuprl system, the PX system and so on, but
the underlying logic is different. The underlying logic is called QJ
that is developed by Professor Sato at Tohoku University. On of the
unique features of QJ is that types and logic are strictly separated
as compared with constructive type theory in which they are mixed.
This formulation allows to write proofs and theorems in a style very
similar to that of ordinary mathematics textbooks.
-------
∂02-Sep-87 1013 @Sushi.Stanford.EDU:GALIL%cs.columbia.edu@forsythe.stanford.edu Warning: The Tenth Columbia University Theory Day
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Sep 87 10:13:42 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Wed 2 Sep 87 10:05:17-PDT
Received: by lindy.stanford.edu; Wed, 2 Sep 87 10:08:38 PDT
Resent-From: GALIL%cs.columbia.edu@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Wed, 2 Sep 87 10:07:12 PDT
Date: Mon 31 Aug 87 16:52:44-EDT
From: Zvi Galil <GALIL%cs.columbia.edu@forsythe.stanford.edu>
Subject: Warning: The Tenth Columbia University Theory Day
Message-Id: <C094.THEORYNT@ibm.com>
Resent-Date: 2 Sep 1987 13:06:55-EDT (Wednesday)
Resent-Sender: THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Resent-To: aflb.tn@sushi.stanford.edu
Apparently-To: aflb.tn@SUSHI.STANFORD.EDU
Please mark your calenders.
The tenth Columbia University Theory Day
will be held on October 1. The four lectures will be:
Shmuel Winograd, IBM Thomas J. Watson Research Center
"Complexity of Matrix Operations."
Alan Borodin, University of Toronto
"Random Walks, Universal Sequences and Log-Space Computation."
Joel Spencer, SUNY at Stonybrook
"Threshold Functions and Zero-One Laws."
Micha Sharir, Tel-Aviv University
"Davenport-Schinzel Sequences and their Geometric Applications."
The full announcement will be broadcasted next week.
Please notice the following changes:
1. it will be held on Thursday and
2. it will be held in a different room (in the same building).
The eleventh theory day will be on Friday April 8 in the
usual room.
-------
∂02-Sep-87 1024 @Sushi.Stanford.EDU:lory%CAF.MIT.EDU@forsythe.stanford.edu Call for Papers
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Sep 87 10:24:12 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Wed 2 Sep 87 10:05:26-PDT
Received: by lindy.stanford.edu; Wed, 2 Sep 87 10:08:48 PDT
Resent-From: lory%CAF.MIT.EDU@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Wed, 2 Sep 87 10:07:31 PDT
Date: Tue, 1 Sep 87 14:36:34 EDT
From: Barbara B. Lory <lory%CAF.MIT.EDU@forsythe.stanford.edu>
Subject: Call for Papers
Message-Id: <C095.THEORYNT@ibm.com>
Resent-Date: 2 Sep 1987 13:05:23-EDT (Wednesday)
Resent-Sender: THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Resent-To: aflb.tn@sushi.stanford.edu
Apparently-To: aflb.tn@SUSHI.STANFORD.EDU
-------------------------------------------------------------------------
Fifth MIT Conference on
ADVANCED RESEARCH IN VLSI
Design and Applications of
Very Large Scale Systems
March 28-30, 1988
Massachusetts Institute of Technology
Cambridge, Massachusetts 02139
The field of VLSI (Very Large Scale Integration) is concerned with the design,
production, and use of highly complex integrated circuits. Many disciplines,
including computer architecture, computer-aided design, parallel algorithms,
semiconductor technology, and testing are involved. In addition, novel uses
of the technology and concepts originally developed for integrated circuits
are emerging, including integrated sensor arrays, digital photography, highly
parallel computers, microactuators, neural networks, and a variety of special-
purpose architectures and networks of special-purpose devices. This
conference, the tenth in a series that has been held at MIT, Caltech, UNC, and
Stanford, deals with all these topics, and attempts to promote interactions
among them.
Original research papers are sought in any of the following or related areas:
Parallel architectures and algorithms VLSI devices and circuits
Special-purpose architectures Neural networks
Fault tolerance Integrated sensors, actuators
Layout and routing and displays
Testing Automated semiconductor manufacturing
Computer-aided design Novel technologies
VLSI theory Wafer-scale systems
VLSI applications
EXTENDED ABSTRACTS of about ten pages (fourteen copies) should be sent by
September 11, 1987, to:
VLSI Conference
Microsystems Research Center
Room 39-321
Massachusetts Institute of Technology
Cambridge, MA 02139
Because of the interdisciplinary nature of this conference, authors are urged
to explain the significance of their work to nonexperts. Notification of
acceptances will be sent to authors by November 2, 1987. Camera-ready copy
will be due January 4, 1988 so that the proceedings can be available at the
conference.
Invited Speakers
Patrick Bosshart (Texas Instruments)
Robert Brayton (IBM)
John Hopfield (CalTech)
Carver Mead (CalTech)
Richard Newton (Berkeley)
Nicholas Pippinger (IBM Almaden Research Center)
Jack I. Raffel (MIT Lincoln Lab)
Arnold L. Rosenberg (U. Mass., Amherst)
Timothy Tredwell (Eastman Kodak)
Attendance Information
The arrangements for the conference will be similar to those of past years at
MIT. Attendance is by invitation. For information or invitations, contact
Registrations, Room 39-321, MIT, Cambridge, MA 02139, telephone (617)
253-8138.
Organization of the Conference
The conference is organized by the MIT Microsystems Research Center. The
conference chairman is Paul Penfield, Jr. The program committee consists of
J. Allen (MIT) and F. T. Leighton (MIT) Co-chairmen, Robert Brayton (IBM),
William J. Dally (MIT), Stephen W. Director (CMU), Henry Fuchs (UNC), Andrea
LaPaugh (Princeton), Thomas Lengauer (U. Paderborn), Gordon D. Robinson
(GenRad), Alberto L. Sangiovanni-Vincentelli (U.C. Berkeley), Thomas G.
Szymanski (AT&T Bell Labs), and Jeffrey D. Ullman (Stanford).
≠
∂02-Sep-87 1052 @Score.Stanford.EDU:JHILL@Sierra.Stanford.EDU Faculty Directory
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Sep 87 10:51:56 PDT
Received: from Sierra.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 2 Sep 87 10:52:00-PDT
Date: Wed 2 Sep 87 10:51:27-PDT
From: Jane S. Hill <JHILL@Sierra.Stanford.EDU>
Subject: Faculty Directory
To: ac@Score.Stanford.EDU
cc: jhill@Sierra.Stanford.EDU
Message-ID: <12331448812.28.JHILL@Sierra.Stanford.EDU>
Members of the Computer Science Faculty,
I am in the process of compiling the faculty resource directory for the entire
School of Engineering. As part of the process, I recently had your department
distribute proofs of the individual biographies for the directory, asking that
they be returned by Wednesday, Sept. 2 - today. If you have not returned your
bio, please do so, else the bio will be inserted as shown and errors or
confusion may result. I need the biographies by tomorrow if they are to be
included. Thank you for your attention to this matter - please return the
proofed copies to either Anne Richardson or the departmental receptionist.
Craig Elston Terman 215 3-9041
-------
∂03-Sep-87 1739 NILSSON@Score.Stanford.EDU Winograd Award
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Sep 87 17:39:18 PDT
Date: Thu 3 Sep 87 17:38:19-PDT
From: Nils Nilsson <NILSSON@Score.Stanford.EDU>
Subject: Winograd Award
To: faculty@Score.Stanford.EDU
Message-ID: <12331785022.38.NILSSON@Score.Stanford.EDU>
I have just learned that Terry Winograd (and his co-author, Fernando
Flores) have been awarded the 1987 American Society for Information
Science Best Information Science Book Award for their book
"Understanding Computers and Cognition." The award will be presented on
October 7, 1987 at the 50th Anniversary Dinner during the ASIS
50th Anniversary Conference. Congratulations to Terry and Fernando!
-Nils
-------
∂04-Sep-87 1040 @WARBUCKS.AI.SRI.COM,@malibu:olender@malibu.ai.sri.com
Received: from WARBUCKS.AI.SRI.COM by SAIL.STANFORD.EDU with TCP; 4 Sep 87 10:40:14 PDT
Received: from malibu by WARBUCKS.AI.SRI.COM via SMTP with TCP; Fri,
4 Sep 87 09:56:51-PDT
Received: by malibu (3.2/4.16) id AA07573 for aic-associates@warbucks;
Fri, 4 Sep 87 09:55:58 PDT
Date: Fri, 4 Sep 87 09:55:58 PDT
From: Margaret Olender <olender@malibu.ai.sri.com>
Message-Id: <8709041655.AA07573@malibu>
To: aic-associates@warbucks, planlunch@warbucks, csl-staff@csl.sri.com
friends@csli.stanford.edu
Subject: TALK BY LYNDON WHILE / IMPERIAL COLLEGE, LONDON.
VISITORS: Please arrive 5 minutes early to be escorted up from the
E-building receptionist's desk.
11:00am, WEDNESDAY, September 9, 1987
SRI International, Building E, Room EJ228
TITLE AND ABSTRACT
CONTROLLING THE BEHAVIOUR OF FUNCTIONAL LANGUAGE SYSTEMS
USING TEMPORAL LOGIC
Lyndon While
Imperial College
London
Functional programming languages, although possessing many advantages,
have certain limitations when they are applied to systems where control
over the program's behaviour is required.
We have developed a methodology that overcomes this limitation without
destroying the pure declrative nature of these languages. Temporal logic
is used to specify any behavioural aspect of the problem and this is
then transformed together with the (pure) functional language program
to produce a program that is guaranteed to satisfy the temporal requirements
however it is implemented.
We will describe the Tempoaral Logic specification language used
together with the transformation rules. This methodology has been
implemented as a completely automatic process and we will give some
examples of its use.
∂04-Sep-87 1108 NILSSON@Score.Stanford.EDU Prize
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 87 11:08:53 PDT
Date: Fri 4 Sep 87 11:08:00-PDT
From: Nils Nilsson <NILSSON@Score.Stanford.EDU>
Subject: Prize
To: faculty@Score.Stanford.EDU
Message-ID: <12331976113.22.NILSSON@Score.Stanford.EDU>
I'm proud to be able to tell everyone that Vladimir Lifschitz received
the "publishers prize" for best paper at the International Joint
Conference on Artificial Intelligence held last week in Milan, Italy.
His paper was entitled "Formal Theories of Action" and appears
in the IJCAI-87 proceedings.
(Recall that Stanford CSD PhD student Ramin Zabih was a co-author on
one of the publishers prizes for best paper at this year's AAAI
National AI Conference. Stanford seems to be keeping its head above
water in AI; although, it must be said, that Ramin's paper reports on
work done at one of the Eastern places.)
Congratulations, Vladimir, we knew that was good stuff!
-Nils
-------
∂04-Sep-87 1130 @Score.Stanford.EDU:FEIGENBAUM@SUMEX-AIM.STANFORD.EDU Re: Prize
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 87 11:30:46 PDT
Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Fri 4 Sep 87 11:29:57-PDT
Date: Fri, 4 Sep 87 11:30:09 PDT
From: Edward Feigenbaum <FEIGENBAUM@SUMEX-AIM.STANFORD.EDU>
Subject: Re: Prize
To: NILSSON@SCORE.STANFORD.EDU, faculty@SCORE.STANFORD.EDU
In-Reply-To: <12331976113.22.NILSSON@Score.Stanford.EDU>
Message-ID: <12331980144.46.FEIGENBAUM@SUMEX-AIM.STANFORD.EDU>
Congratulations, Vladimir!
Nils, what do you mean "Stanford is keeping its head above water in AI"?
I thought we were the best!
Ed
-------
∂04-Sep-87 1250 REGES@Score.Stanford.EDU TA assignments
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 87 12:50:52 PDT
Date: Fri 4 Sep 87 12:49:23-PDT
From: Stuart Reges <REGES@Score.Stanford.EDU>
Subject: TA assignments
To: faculty@Score.Stanford.EDU
Office: CS-TAC 22, 723-9798
Message-ID: <12331994569.36.REGES@Score.Stanford.EDU>
I will be making the major round of TA assignments on Tuesday next week. If
you have any preferences that you haven't yet stated, please do so now. I'm
trying to make appointments for the entire academic year, so you should tell me
preferences for Winter and Spring in addition to Fall.
I'm also sending a reminder to PhD students that they should be sure to have an
application on file with us if they are going to need a TA position for
support, but if you have any surprises to spring on your graduate students, you
should probably do so now. Last year I had some PhD students coming in as late
as the first day of classes telling me, "My advisor just told me that he can't
support me. Can you help me?" This year the answer will probably be "no" for
people who come in that late.
-------
∂04-Sep-87 1317 NILSSON@Score.Stanford.EDU libraries
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 87 13:17:38 PDT
Date: Fri 4 Sep 87 13:16:49-PDT
From: Nils Nilsson <NILSSON@Score.Stanford.EDU>
Subject: libraries
To: faculty@Score.Stanford.EDU
Message-ID: <12331999562.10.NILSSON@Score.Stanford.EDU>
I need your guidance about what we ought to do about our
"library needs" in the future.
Here's how I see the situation at present:
1) We (CS) are reasonably happy with the present set-up in
which we use the Math/CS library. We like the way they run
things (more-or-less), we like their policy of not getting
rid of pre-1970 journals, we like the location, and we like the
convenience of being able to find math and statistics writings
right there also. (As a contrast, we don't think very much
of the way things are done in the Terman Engrg. Libe.)
2) Math doesn't like us nearly as much as we like (?) them.
They want us out of "their" library. (Maybe not because we
are undesireables but because we take up a lot of space that they
want to grow into.) The math faculty has met to empower their
chairman to represent strongly to the university library committee
that in the future the math library have just math and statistics
(possibly Operations Research), but NOT computer science.
3) The Near West Campus planning is causing the libraries to consider
how they want to re-organize, centralize, change, etc. There will
probably be some kind of central scientific library in the NWC (probably
in the building just south of Sox). Math very definitely doesn't want
their library to move to the NWC. If it has to move, they would like it
to move to Margaret Jacks Hall (after we move out).
4) There is talk in library circles of combining computer science with
E.E. and physics, as far as libraries are concerned (in the NWC).
5) I have told the library people that we don't have very much overlap
with most of E.E. nor physics (while admitting that maybe EE and physics
have overlap and saying that we and parts of math have the same kind
of overlap).
6) I met with Sol Feferman, gauged the depths of math's feelings on this
issue and, at least at that meeting, decided not to push for inclusion
with math.
7) If I (we) do nothing, we'll probably get some story from the central
people that our library needs are going to be elegantly dealt with by
combining us with EE/Physics in a building south of Sox.
8) We might be able to push for our own CS library (in Nox or Sox).
Should I do that?
9) If we want to push for continuing, long-term inclusion with
math/statistics, we will have to help figure out how that library can
have more space. Probably the central people (the library authorities)
won't give them more space, and even if they did it might be in some
location math doesn't like. (Maybe we won't like it either.)
Comments, suggestions, solutions will be appreciated. -Nils
-------
∂04-Sep-87 1328 ENGELMORE@SUMEX-AIM.STANFORD.EDU The next DARPA workshop
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 87 13:28:22 PDT
Date: Fri, 4 Sep 87 13:27:57 PDT
From: Bob Engelmore <Engelmore@SUMEX-AIM.STANFORD.EDU>
Subject: The next DARPA workshop
To: aap@SUMEX-AIM.STANFORD.EDU
Office-Phone: (415) 723-8444
Message-ID: <12332001590.36.ENGELMORE@SUMEX-AIM.STANFORD.EDU>
The semiannual DARPA meeting which we normally attend will apparently be of a
different flavor this time (Oct. 21-23), and the architectures group is not
invited. The workshop is entirely about planning. I found this out from
Raj Wall at TI. The only KSL person invited will by that time be an ex-KSL
person, Paul Rosenbloom.
I for one am delighted that I don't have to attend. Is anyone disappointed?
Bob
-------
∂04-Sep-87 1628 FEIGENBAUM@SUMEX-AIM.STANFORD.EDU Re: The next DARPA workshop
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 87 16:28:53 PDT
Date: Fri, 4 Sep 87 16:28:15 PDT
From: Edward Feigenbaum <FEIGENBAUM@SUMEX-AIM.STANFORD.EDU>
Subject: Re: The next DARPA workshop
To: Engelmore@SUMEX-AIM.STANFORD.EDU, aap@SUMEX-AIM.STANFORD.EDU
In-Reply-To: <12332001590.36.ENGELMORE@SUMEX-AIM.STANFORD.EDU>
Message-ID: <12332034411.37.FEIGENBAUM@SUMEX-AIM.STANFORD.EDU>
My view is: that's great!......Ed
-------
∂04-Sep-87 2240 @Score.Stanford.EDU:cheriton@pescadero.Stanford.EDU Re: libraries
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 87 22:39:55 PDT
Received: from pescadero.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 4 Sep 87 22:38:27-PDT
Received: by pescadero.Stanford.EDU; Fri, 4 Sep 87 22:18:02 PDT
Date: Fri, 4 Sep 87 22:18:02 PDT
From: David Cheriton <cheriton@pescadero.Stanford.EDU>
To: NILSSON@score.stanford.edu, faculty@score.stanford.edu
Subject: Re: libraries
I would like to revive my idea of a "caching library", which only stores
stuff which is in active use by some measure. Socrates could be used
to determine where something is located. I think one reasonable approach
would be a csd/csl caching library right in our building plus a backing
storage library in with the EE/Physics nightmare, or in with some large
operation.
In general, it is crazy to try to store all things in prime locations,
and crazy to store prime material in a poor location because of the bulk
of the seldom referenced. It's time we focus on pleasing most of the people
most of the time, or some diplomatic version of this.
I sympathize with the math people to the degree that there is a lot of
PC junk in the math library (I understand). However, there seems to be
a lot of snobbery at work as well. Maybe we should ask the university to
allocate space in the Math/CS library based on relative research overheads
paid by the two departments?
David C.
∂06-Sep-87 1227 NILSSON@Score.Stanford.EDU Apple
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Sep 87 12:27:14 PDT
Date: Sun 6 Sep 87 12:26:07-PDT
From: Nils Nilsson <NILSSON@Score.Stanford.EDU>
Subject: Apple
To: faculty@Score.Stanford.EDU
Message-ID: <12332514620.12.NILSSON@Score.Stanford.EDU>
Apple Computer has invited "the Stanford CSD" to visit Apple to
talk about representative research here. They have in mind having
3 or 4 faculty members visiting and each describing for a few minutes
what he is doing. Presumably Apple will tell us a bit about what
they are up to. We won't have time in the first visit to talk
about everything happening in cs at Stanford, but we can give them
some examples. If you would like to be considered to be part of this
during a visit in early Fall Quarter, pse respond to this message
saying (in a phrase) what you would talk about. (Anne, can you
pls collect the responses?) -Nils
-------
∂08-Sep-87 0925 BSCOTT@Score.Stanford.EDU Personal Phone Calls
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Sep 87 09:25:07 PDT
Date: Tue 8 Sep 87 09:24:52-PDT
From: Betty Scott <BSCOTT@Score.Stanford.EDU>
Subject: Personal Phone Calls
To: AC@Score.Stanford.EDU
cc: AU.CJB@Forsythe.Stanford.EDU, BScott@Score.Stanford.EDU
Message-ID: <12333005914.17.BSCOTT@Score.Stanford.EDU>
Stanford's Internal Audit Department has asked me to let you know that no
long distance personal phone calls should be charged to any University account
number. If you wish to make personal calls from your office phone, you should
obtain a calling card and charge such calls to this card.
Betty
-------
∂08-Sep-87 1251 TOM@Score.Stanford.EDU Campus wide power shut down
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Sep 87 12:51:42 PDT
Date: Tue 8 Sep 87 12:50:07-PDT
From: Thomas Dienstbier <TOM@Score.Stanford.EDU>
Subject: Campus wide power shut down
To: su-computers@Score.Stanford.EDU, staff@Score.Stanford.EDU,
faculty@Score.Stanford.EDU
cc: tom@Score.Stanford.EDU
Message-ID: <12333043278.29.TOM@Score.Stanford.EDU>
Reminder that this saturday Sept. 12, most of the campus will be without
power starting at 0700 thru 1200. All computers in Margaret Jacks will be
shut down starting at 0645.
tom
-------
∂08-Sep-87 1635 SLOAN@Score.Stanford.EDU Sharon Hemenway
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Sep 87 16:35:02 PDT
Date: Tue 8 Sep 87 16:29:16-PDT
From: Yvette Sloan <SLOAN@Score.Stanford.EDU>
Subject: Sharon Hemenway
To: CSD@Score.Stanford.EDU, Faculty@Score.Stanford.EDU,
Staff@Score.Stanford.EDU, Students@Score.Stanford.EDU
Message-ID: <12333083173.43.SLOAN@Score.Stanford.EDU>
This is to let you know that Sharon Hemenway began work as Graduate Programs
Administrator in CS this morning. If you have not met her, please stop by
MJH 258 to introduce yourself and to welcome her to the Department.
-----Yvette
-------
∂08-Sep-87 2106 @WARBUCKS.AI.SRI.COM,@malibu:olender@malibu.ai.sri.com [olender: TALK BY LYNDON WHILE / IMPERIAL COLLEGE, LONDON.]
Received: from WARBUCKS.AI.SRI.COM by SAIL.STANFORD.EDU with TCP; 8 Sep 87 21:06:04 PDT
Received: from malibu by WARBUCKS.AI.SRI.COM via SMTP with TCP; Tue,
8 Sep 87 15:29:50-PDT
Received: by malibu (3.2/4.16) id AA10350 for aic-associates@warbucks;
Tue, 8 Sep 87 15:29:12 PDT
Date: Tue, 8 Sep 87 15:29:12 PDT
From: Margaret Olender <olender@malibu.ai.sri.com>
Message-Id: <8709082229.AA10350@malibu>
To: aic-associates@warbucks, planlunch@warbucks, csl-staff@csl.sri.com
Subject: [olender: TALK BY LYNDON WHILE / IMPERIAL COLLEGE, LONDON.]
Date: Fri, 4 Sep 87 09:55:58 PDT
From: Margaret Olender <olender>
To: aic-associates@warbucks, planlunch@warbucks, csl-staff@csl.sri.com
friends@csli.stanford.edu
Subject: TALK BY LYNDON WHILE / IMPERIAL COLLEGE, LONDON.
VISITORS: Please arrive 5 minutes early to be escorted up from the
E-building receptionist's desk.
11:00am, WEDNESDAY, September 9, 1987
SRI International, Building E, Room EJ228
TITLE AND ABSTRACT
CONTROLLING THE BEHAVIOUR OF FUNCTIONAL LANGUAGE SYSTEMS
USING TEMPORAL LOGIC
Lyndon While
Imperial College
London
Functional programming languages, although possessing many advantages,
have certain limitations when they are applied to systems where control
over the program's behaviour is required.
We have developed a methodology that overcomes this limitation without
destroying the pure declrative nature of these languages. Temporal logic
is used to specify any behavioural aspect of the problem and this is
then transformed together with the (pure) functional language program
to produce a program that is guaranteed to satisfy the temporal requirements
however it is implemented.
We will describe the Tempoaral Logic specification language used
together with the transformation rules. This methodology has been
implemented as a completely automatic process and we will give some
examples of its use.
∂09-Sep-87 1027 FEIGENBAUM@SUMEX-AIM.STANFORD.EDU funny slogan
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Sep 87 10:27:18 PDT
Date: Wed, 9 Sep 87 10:25:24 PDT
From: Edward Feigenbaum <FEIGENBAUM@SUMEX-AIM.STANFORD.EDU>
Subject: funny slogan
To: aap@SUMEX-AIM.STANFORD.EDU, ssrg@SUMEX-AIM.STANFORD.EDU
Message-ID: <12333279077.74.FEIGENBAUM@SUMEX-AIM.STANFORD.EDU>
here's a good slogan for Symbolics:
"if we can't fix it, it ain't broke"
Ed
-------
∂09-Sep-87 1033 RINDFLEISCH@SUMEX-AIM.STANFORD.EDU Re: funny slogan
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Sep 87 10:33:30 PDT
Date: Wed, 9 Sep 87 10:27:40 PDT
From: TC Rindfleisch <Rindfleisch@SUMEX-AIM.STANFORD.EDU>
Subject: Re: funny slogan
To: FEIGENBAUM@SUMEX-AIM.STANFORD.EDU, aap@SUMEX-AIM.STANFORD.EDU,
ssrg@SUMEX-AIM.STANFORD.EDU
cc: Rindfleisch@SUMEX-AIM.STANFORD.EDU
In-Reply-To: <12333279077.74.FEIGENBAUM@SUMEX-AIM.STANFORD.EDU>
Message-ID: <12333279490.23.RINDFLEISCH@SUMEX-AIM.STANFORD.EDU>
Sounds right to me... Tom R.
-------
∂09-Sep-87 1118 CRISPIN@SUMEX-AIM.STANFORD.EDU re: funny slogan
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Sep 87 11:18:50 PDT
Date: Wed, 9 Sep 87 11:16:27 PDT
From: Mark Crispin <Crispin@SUMEX-AIM.STANFORD.EDU>
Subject: re: funny slogan
To: SSRG@SUMEX-AIM.STANFORD.EDU, AAP@SUMEX-AIM.STANFORD.EDU,
Feigenbaum@SUMEX-AIM.STANFORD.EDU
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12333288371.79.CRISPIN@SUMEX-AIM.STANFORD.EDU>
How about: "Symbolics will fix no machine before its time."
-------
∂09-Sep-87 1148 ENGELMORE@SUMEX-AIM.STANFORD.EDU re: funny slogan
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Sep 87 11:48:29 PDT
Date: Wed, 9 Sep 87 11:47:00 PDT
From: Bob Engelmore <Engelmore@SUMEX-AIM.STANFORD.EDU>
Subject: re: funny slogan
To: Crispin@SUMEX-AIM.STANFORD.EDU, SSRG@SUMEX-AIM.STANFORD.EDU,
AAP@SUMEX-AIM.STANFORD.EDU, Feigenbaum@SUMEX-AIM.STANFORD.EDU
In-Reply-To: <12333288371.79.CRISPIN@SUMEX-AIM.STANFORD.EDU>
Office-Phone: (415) 723-8444
Message-ID: <12333293933.34.ENGELMORE@SUMEX-AIM.STANFORD.EDU>
"Maintenance is a Symbolic activity."
-------
∂10-Sep-87 0936 RICHARDSON@Score.Stanford.EDU Faculty Meeting
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 10 Sep 87 09:36:51 PDT
Date: Thu 10 Sep 87 09:32:44-PDT
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: Faculty Meeting
To: faculty@Score.Stanford.EDU
cc: eileen@Sierra.Stanford.EDU
Message-ID: <12333531635.15.RICHARDSON@Score.Stanford.EDU>
There will be a faculty meeting on Tuesday, September 29 at 2:30 to vote on
degree candidates. Should you have any additional agenda items that you would
like to have included, please let me know. (I will announce the location at
a later date.)
-Anne
-------
∂11-Sep-87 1019 @Sushi.Stanford.EDU:siri%imag.uucp%mcvax@forsythe.stanford.edu ACM-SIGIR88
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Sep 87 10:18:58 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Fri 11 Sep 87 10:11:49-PDT
Received: by lindy.stanford.edu; Fri, 11 Sep 87 10:12:10 PDT
Resent-From: siri%imag.uucp%mcvax@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Fri, 11 Sep 87 10:10:55 PDT
Date: Tue, 8 Sep 87 11:59:38 +0200
From: siri%imag.uucp%mcvax.BITNET@forsythe.stanford.edu (Equipe Chiaramella)
Subject: ACM-SIGIR88
Message-Id: <C096.THEORYNT@ibm.com>
Resent-Date: 11 Sep 1987 13:07:01-EDT (Friday)
Resent-Sender: THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Resent-To: aflb.tn@sushi.stanford.edu
Apparently-To: aflb.tn@sushi.stanford.edu
CALL FOR PAPERS
SIGIR 88
in cooperation with the ACM
11th INTERNATIONAL CONFERENCE
ON
RESEARCH AND DEVELOPMENT IN INFORMATION RETRIEVAL
ACM-SIGIR
JUNE 13-15 1988
GRENOBLE (FRANCE)
Conference Chairman : Yves CHIARAMELLA (USTMG - Grenoble, France)
-------------------
Program Comittee :
----------------
M.ADIBA (F) G.KNORZ (Germany)
R.BOUCHE (F) S.MIRANDA (F)
A.BOOKSTEIN (USA) C.D.PAICE (UK)
M.F.BRUANDET (F) F.RABITTI (I)
E.CHOURAQUI (F) V.V.RAGHAVAN (USA)
W.B.CROFT (USA) K.VAN RIJSBERGEN (UK)
T.E.DOSZKOCS (USA) G.SALTON (USA)
A.S. FRAENKEL (Israel) P.WILLETT (UK)
N.FUHR (Germany) S.K.M. WONG (Canada)
Papers are invited on theory, methodology, implementation and applications of
information retrieval.
Communications from areas of prime interest for information retrieval, such
as artificial intelligence, database systems, office automation, hardware
technology, natural language processing, are welcome.
The main topics thus include, but are not limited to:
- retrieval system modelling :
linguistic models
mathematical models
cognitive and semantic models
- information retrieval and artificial intelligence:
knowledge representation
expert systems
thesaurus management
- evaluation techniques:
retrieval and system performances
system development and evaluation
- natural language processing:
parsers
deep understanding
multilingual systems
- information retrieval and database management:
storage and research techniques
multimedia databases
fifth generation databases
deductive databases
document databases for ofice automation
database machines
- user interfaces:
natural language interfaces
graphic interfaces
- advanced applications
INSTRUCTIONS TO AUTHORS :
-----------------------
Full length papers should not exceed 20 or 25 pages. Extented abstracts of
about 10 pages are also accepted. Both must contain a complete author
identification and an abstract of about a hundred words. Four copies of each
paper should be submitted to the Program Committee. Papers from North America
should be sent to G.SALTON; submissions from outside North America should be
sent to E.CHOURAQUI:
Gerard SALTON Eugene CHOURAQUI
CORNELL UNIVERSITY GRTC-CNRS
Dept. of Computer Science 31 chemin J.AIGUIER
4130 UPSON HALL 13402 MARSEILLE
ITHACA Cedex 9
N.Y. 14853 - 7501 USA FRANCE
Important dates :
---------------
submission deadline : january 15, 1988
acceptance notification : march 21, 1988
final copy due : may 16, 1988
Communication ways :
------------------
electronic address : siri@imag.UUCP
telex address : 98 01 34
telecopy address : 76 51 48 48
==============================================================================
= SIGIR 88 - REPLY MESSAGE : =
= ------------------------- =
= =
= Please return to Y.CHIARAMELLA =
= - electronic address : siri @ imag .UUCP =
= - mail address : Laboratoire IMAG - Genie Informatique =
= BP 38 - 38402 Saint Martin d'Heres Cedex =
= FRANCE =
= =
= Last Name, First Name : ------------------------------------- =
= Address : --------------------------------------------------- =
= --------------------------------------------------- =
= --------------------------------------------------- =
= Electronic address : ---------------------------------------- =
= - I intend to participate the Conference =
= and want to receive the final program =
= =
= - I intend to submit a paper : - selected topic : =
= - previsional title : =
= =
= =
==============================================================================
∂11-Sep-87 1201 @Score.Stanford.EDU:EJM@Sierra.Stanford.EDU Apple
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Sep 87 12:01:45 PDT
Received: from Sierra.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 11 Sep 87 12:00:29-PDT
Date: Fri 11 Sep 87 11:59:56-PDT
From: Ed McCluskey <EJM@Sierra.Stanford.EDU>
Subject: Apple
To: faculty@Score.Stanford.EDU
cc: ejm@Sierra.Stanford.EDU
Message-ID: <12333820574.13.EJM@Sierra.Stanford.EDU>
Apple visit response in a phrase: CRC - Research into Built-in
Self-test and Maintenance for temporary as well as hard failures.
E.J. McCluskey
-------
∂11-Sep-87 1409 @Sushi.Stanford.EDU:GALIL%cs.columbia.edu@forsythe.stanford.edu The Tenth Columbia University Theory Day
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Sep 87 14:09:03 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Fri 11 Sep 87 13:59:25-PDT
Received: by lindy.stanford.edu; Fri, 11 Sep 87 13:59:49 PDT
Resent-From: GALIL%cs.columbia.edu@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Fri, 11 Sep 87 13:58:13 PDT
Date: Tue 8 Sep 87 10:27:04-EDT
From: Zvi Galil <GALIL%cs.columbia.edu@forsythe.stanford.edu>
Subject: The Tenth Columbia University Theory Day
Message-Id: <C097.THEORYNT@ibm.com>
Resent-Date: 11 Sep 1987 16:54:19-EDT (Friday)
Resent-Sender: THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Resent-To: aflb.tn@sushi.stanford.edu
Apparently-To: aflb.tn@sushi.stanford.edu
THE TENTH THEORY DAY
at Columbia University
SPONSORED BY THE DEPARTMENT OF COMPUTER SCIENCE
Thursday, October 1, 1987
10:00 DR. SHMUEL WINOGRAD
IBM, T.J. Watson Research Center
COMPLEXITY OF MATRIX OPERATIONS
11:00 PROFESSOR ALAN BORODIN
University of Toronto
RANDOM WALKS, UNIVERSAL SEQUENCES
AND LOG-SPACE COMPUTATION
2:00 PROFESSOR JOEL SPENCER
SUNY at Stony Brook
THRESHOLD FUNCTIONS AND ZERO-ONE LAWS
3:00 PROFESSOR MICHA SHARIR
Tel-Aviv University
DAVENPORT-SCHINZEL SEQUENCES
AND THEIR GEOMETRIC APPLICATIONS
Coffee will be available at 9:30 a.m.
All lectures will be in the Dag Hammarskjold Lounge on the sixth
floor of the International Affairs Building, 118th Street and
Amsterdam Avenue.
The lectures are free and open to the public.
Call (212) 280-2736 for more information.
-------
∂11-Sep-87 1419 @Sushi.Stanford.EDU:chazelle%Princeton.EDU@forsythe.stanford.edu call for papers
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Sep 87 14:18:55 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Fri 11 Sep 87 13:59:58-PDT
Received: by lindy.stanford.edu; Fri, 11 Sep 87 14:00:25 PDT
Resent-From: chazelle%Princeton.EDU@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Fri, 11 Sep 87 13:58:59 PDT
Date: Fri, 11 Sep 87 15:06:23 EDT
From: chazelle%Princeton.EDU@forsythe.stanford.edu (Bernard Chazelle)
Subject: call for papers
Message-Id: <C098.THEORYNT@ibm.com>
Resent-Date: 11 Sep 1987 16:52:38-EDT (Friday)
Resent-Sender: THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Resent-To: aflb.tn@sushi.stanford.edu
Apparently-To: aflb.tn@sushi.stanford.edu
CALL FOR PAPERS
Fourth Annual ACM Symposium on
COMPUTATIONAL GEOMETRY
6-8 June 1988
University of Illinois
Urbana-Champaign, Illinois
Papers presenting original research in
computational geometry are being sought. Suggested
topic areas include (but are not limited to):
* design and analysis of geometric algorithms
* data structures for computational geometry
* applications with a geometric flavor, including
-- robotics: collision avoidance, motion planning
-- computer graphics: hidden surface and rendering algorithms
-- solid modeling and freeform surface modeling
-- pattern recognition: shape decomposition
* mathematical bases for computational geometry
* issues arising from the implementation of geometric algorithms
* programming language issues in computational geometry
Authors should send eleven (11) copies of an extended abstract
by December 15, 1987 to the Program Committee Chair:
Bernard Chazelle
Department of Computer Science
Princeton University
Princeton, NJ 08544
Late submissions risk rejection without further consideration.
Authors will be notified of acceptance or rejection by February
9, 1988. A copy of each accepted paper, typed on model paper, will be due
by March 16, 1988, for inclusion in the proceedings.
Authors are advised to prepare their extended abstracts carefully.
Each submission should begin with a succinct
statement of the problems, the main results, and the
significance of the work in the context of previous research.
The extended abstract (not a full paper)
should provide sufficient detail
to allow the program committee to evaluate the quality of the
contribution and its appropriateness to the
conference. The entire extended abstract should not exceed
10 double-spaced pages.
The Symposium is sponsored by ACM SIGACT and SIGGRAPH. Proceedings
will be distributed at the Symposium and will be subsequently available
for purchase from ACM.
Symposium Committees
Program Committee Conference Chair
Chanderjit Bajaj V. Thomas Rajan Herbert Edelsbrunner
Bernard Chazelle Richard Riesenfeld Department of Computer Science
Patrick Hanrahan Raimund Seidel University of Illinois
David Kirkpatrick Robert Tarjan 1304 West Springfield Ave.
Kurt Mehlhorn Christopher Van Wyk Urbana, IL 61801
Richard Pollack
∂11-Sep-87 1458 ullman@nimbin.stanford.edu
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Sep 87 14:58:02 PDT
Received: from nimbin (nimbin.Stanford.EDU) by navajo.stanford.edu with TCP; Fri, 11 Sep 87 14:48:58 PDT
Date: Fri Sep 11 14:32:25 1987 PST
From: ullman@nimbin.stanford.edu
Message-Id: <8708111432.AA4928@nimbin>
To: nail@navajo.stanford.edu
subject: papers received
"A simple implementation of an interpreter for general logic
programs under tight tree semantics" H. Seki, ICOT
The idea is that one can "memo" or remember all facts derived in
response to a given subquery, thus avoiding the pitfall of
typical top-down algorithms: infinite loops and/or repeating
work that was done before and thrown away.
As a result, the performance of top-down becomes AT LEAST as good
as magic sets in any of its variations, with one proviso:
Magic sets, working bottom-up, may allow some optimization of
joins, as we evaluate rule bodies. Top-down is inherently
tuple-at-a-time.
One might also argue that the space and retrieval costs of memoing+TD
makes this approach too expensive, but BU also "memos" the
same data as it constructs the least fixed-point.
The bottom line is that I have become less convinced that magic-sets,
i.e., preprocessing of rules + BU computation. is the only way to
go for Datalog.
"Magic Set Computation for Stratified Databases,"
I. Balbin, G. S. Port, and K. Ramamohanarao, Univ. of Melbourne
The problem is that if one is not careful, when you apply
a magic-sets transformation to stratified Datalog with negation,
you can get rules that are not stratified.
They define two notions of "safety" of rules (called "allowed").
One, which I'll call bottom-up safe, is the usual notion:
Every variable of the rule must appear in a POSITIVE subgoal.
The second, "top-down safe" is defined with respect to an
adornment, that is, a set of bound arguments for the head.
It requires that every variable of the rule either appear in
a positive subgoal or a bound argument of the head.
The difference is seen in
p(X,Y) :- q(Y,Z) & not r(Z,X).
This is not BU safe; if you try to compute the relation for the
body from q and r, you have nothing with respect to which you can
compelemnt r, i.e., there is no limit to the set of possible X's.
On the other hand, proceeding top down, if you have a binding for X
from the head, say set x0, you can complement r by subtracting it
from pi_Z(q) * x0, so it is rightly considered TD safe (with
respect to adornment p↑bf).
Their main idea, as far as I see it, is a construction that takes
any set of rules and a query, such that the rules are TD safe for that
query (and presumably a decision as to how information is
passed sideways in each rule, so the adornments for the various rules
can be established). The output of the construction is a revised
set of rules that are BU safe and can answer the query bottom-up
in an "efficient" manner; i.e., a "magic sets" transformation
has been applied.
RESEARCH SUGGESTION
Listening to these two speakers, who came by this week makes me think
that there is some hope of putting "magic sets" on a more-than-ad-hoc
basis. Seki made the remark that he could prove (a variant of)
his method equivalent to the "Alexander method," which he takes
to mean Generalized, Supplementary magic sets in the sense of
Beeri and Ramakrishnan (apparently Rohmer now agrees that this
is what he meant all along).
We should be going the other way around. For each of the
variants of magic sets, we should show that the algorithm
"looks at" the same set of facts as some form of top-down algorithm.
The reason is that top-down naturally limits the scope of what it
looks at, and is therefore the ideal in that regard.
In the past, I (we) have justified magic sets by saying that
it restricts the set of facts that get proved, (that is the
way Beeri and Ramakrishnan argue optimiality). Now, there is the opportunity
to "prove" goodness of magic sets by showing it is no worse than
a particular TD algorithm.
---jeff
∂12-Sep-87 1644 @Score.Stanford.EDU:NOWICK@Sushi.Stanford.EDU Invitation to New Student Brunch
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Sep 87 16:44:32 PDT
Received: from Sushi.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sat 12 Sep 87 16:40:53-PDT
Date: Sat 12 Sep 87 15:36:07-PDT
From: Steven M. Nowick <NOWICK@Sushi.Stanford.EDU>
Subject: Invitation to New Student Brunch
To: Faculty@Score.Stanford.EDU, SrStaff@Score.Stanford.EDU
Message-ID: <12334122073.9.NOWICK@Sushi.Stanford.EDU>
The Orientation Committee of the Computer Science Department
cordially invites you to attend the New Student Brunch, on Sunday,
September 27, from 11 a.m. to 1 p.m. Professor Jeffrey Ullman has
graciously offered to host the brunch at his home at 1023 Cathcart Way,
Stanford.
As in past years, the brunch is an important and pleasant
opportunity for incoming masters and Ph.D. students to meet faculty,
staff, student advisers and each other. It is also the first
organized departmental activity of the academic year, and, for
many incoming students, it is the first opportunity to meet others
from the department.
Directions to Professor Ullman's house are:
From Campus:
Take Campus Drive to Bowdoin Street (next block
on Campus Drive beyond Escondido Road -- heading away
from Serra Street). Make a left on Bowdoin Street.
Continue on Bowdoin until you reach Stanford Avenue.
Go right on Stanford Avenue until Peter Coutts Road.
Make a left on Peter Coutts Road until Raimundo Way.
Go right on Raimundo Way a short distance, and turn
left on Cathcart Way. Prof. Ullman's house is at
1023 Cathcart Way.
From Palo Alto/Mountain View:
Take El Camino Real to Page Mill Road. Go
west on Page Mill Road (in the direction of the
Foothill Expressway intersection). Continue on
Page Mill Road until Peter Coutts Road (next inter-
section beyond Hanover Street). Make a right turn
onto Peter Coutts Road. Then turn left onto
Raimundo Way. After a short distance, turn left
onto Cathcart Way. Prof. Ullman's house is at
1023 Cathcart Way.
Looking forward to seeing you there.
-Steve Nowick
CSD Orientation Committee
-------
∂14-Sep-87 0123 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #58
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 14 Sep 87 01:23:44 PDT
Date: Sun 13 Sep 1987 20:55-PDT
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #58
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Monday, 14 Sep 1987 Volume 5 : Issue 58
Today's Topics:
Announcements - CADE9 & FGCS '88
----------------------------------------------------------------------
Date: Sun 13 Sep 87 20:22:07-PDT
From: Chuck Restivo <Restivo@Sushi.Stanford.EDU>
Subject: CADE-9
CADE-9
9th International Conference on Automated Deduction
May 23-26, 1988
Preliminary Announcement and Call for Papers
CADE-9 will be held at Argonne National Laboratory in celebration of
the 25th anniversary of the discovery of the resolution principle at
Argonne in the summer of 1963. Papers are invited in the following or
related fields:
Theorem Proving Logic Programming
Unification Deductive Databases
Term Rewriting Theorem Proving for Non-Standard Logics
Program Verification Inference Systems
Program Synthesis Applications
{/it Long papers} (up to 5000 words) are for established results.
{/it Short papers} (up to 2500 words) are for succinct results of
ongoing research. Also solicited are system summaries describing
working reasoning systems (up to 500 words) and problem sets providing
realistic yet interesting challenges for automated reasoning systems.
Six copies should be sent to arrive before November 23rd, 1987 to
Ewing Lusk and Ross Overbeek, chairmen
CADE-9
Mathematics and Computer Science Division
Argonne National Laboratory
Argonne, IL 60439_
------------------------------
Date: Sun 13 Sep 87 20:51:03-PDT
From: Chuck Restivo <Restivo@Sushi.Stanford.EDU>
Subject: FGCS '88
FGCS '88
Call For Papers
International Conference on Fifth Generation Computer Systems 1988
Tokyo, Japan
28 November - 2 December 1988
FGCS '88 is an international conference following on from the last
conference, FGCS'84. The conference will last for five days. The
first two will be primarily devoted to reporting FGCS project's
results while the last three will involve technical sessions for
presentation of papers and related discussions.
The scope of technical sessions includes the technical aspects of
new generation computer systems which are particularly within the
framework of knowledge information processing, logic programming and
parallel architectures. This conference is intended to promote
interaction among researchers in all disciplines related to fifth
generation computer technology. Of special interest are papers
discussing future directions or prospects of new generation computing.
The topics of interest include the following:
Software Architecture
Logic/functional/object-oriented Inference machines
Parallel programming languages Knowledge base machines
and methodologies Parallel
Programming verification/debugging VLSI
Program analysis/transformation Human-machine
Applications Foundations
Knowledge based systems Automated Reasoning
NL understanding Theory of parallel computation
Real-time systems Formal Semantics
Paralle systems Foundations of AI
Games and simulation New Generation prospects
Social Impact of FGCS
Authors should send six copies of manuscripts to:
Prof. Hidehiko Tanaka
FGCS'88 Program Chairman
ICOT
MITA Kolusai Bldg.21F
1-4-28 Mita, Minato-ku
Tokyo 108, Japan
Papers must be received by 10 May, 1988
Papers are restricted to 20 double-spaced (about 5000 words) including
figures. Each paper must contain a 200-250 word abstract. Papers
must be written and presented in English.
Papers will be reviewed by international referees. Authors will be
notified of acceptance by 15 July 1988 and will be given instructions
for final preparation of their papers at that time. Camera ready
papers for the proceedings should be sent to the program Chairman
prior to 15 September 1988.
General Information
Venue: Tokyo Prince Hotel, Tokyo, Japan
General sessions
Keynote speeches
Report on progress of Japan's 5th Generation project
Panel discussions
Technical sessions (parallel sessions)
Presentation by invited speakers
Presentation of submitted papers
Special events
Some of the research results including parallel software and
hardware systems, natural language understanding systems and expert
systems will be demonstrated at the conference site.
For further information contact the Secretariat:
FGCS'88 Secretariat
ICOT
Mita Kokusai Bldg.21F
1-4-28 Mita, Minato-ku
Tokyo 108, Japan
tel. 03.456.3195 telex. 3264 ICOT
------------------------------
End of PROLOG Digest
********************
∂15-Sep-87 0152 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #59
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 15 Sep 87 01:52:11 PDT
Date: Mon 14 Sep 1987 12:05-PDT
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #59
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Tuesday, 15 Sep 1987 Volume 5 : Issue 59
Today's Topics:
Query - Implementation Papers & WAM & Linking Turbo,
Announcement - ASPLOS-II Program
----------------------------------------------------------------------
Date: 25 Jun 87 23:18:35 GMT
From: mcvax!dutrun!dutesta!elvis@seismo.css.gov (h)
Subject: Implementation papers (?)
I've read your question about Prolog implementations. I've also read a
reply on the news that you should buy Campbells book on Prolog
implementations. You can do that, but the book, although quite recent
is more or less out of date. At the moment I am writing a report on
Prolog implementations for my study; I am a student of the Technical
University Delft (Holland). What the book doesn't cover at all are
the theoretic advances being made by David Warren He's made a
theoretical model of a Prolog machine, nowadays called the WAM (Warren
Abstract Machine), and it has become the de facto standard for Prolog
implementations. Sadly enough there is -as far as i know- *no* good
book on Prolog implementations. I get my information by searching in
scientific publications. I think that what you need is my report,
once it's finished. Although I am not yet too confident about the
quality of my report, at the very least it will contain an overview of
quite a lot of literature references. Interested? Let me know.
Greetings,
------------------------------
Date: 11 Sep 87 12:43:30 GMT
From: mcvax!dutrun!dutesta!elvis@seismo.css.gov (h)
Subject: Information wanted on the Warren Abstract Machine
I am a student of the Technical University of Delft in Holland and I am
currently writing a report on the Warren Abstract Machine.
I am looking for recent literature on the following topics:
- Warren Abstract and related machine
- implementation of the Warren Abstract Machine
- revision of the Warren Abstract Machine.
I have already read the article:
Tutorial on the Warren Abstract Machine for Computational Logic
by John Gabriel, e.a., June 1985.
I would appreciate any information.
-- R. Tjon
------------------------------
Date: 24 Aug 87 15:02:38 GMT
From: Bob Rennick <uunet!mnetor!utzoo!dciem!nrcaer!ragno!rennick@seismo>
Subject: Linking fortran and turbo-provlog
Borland's manual is not to explicit on the subject, could someone
please help. Examples with parameter passing of all types would be
appreciated. Which compiler is best for ease and efficiency ?
-- Stanley Moran
------------------------------
Date: 28 Aug 87 23:23:41 GMT
From: Martin Freeman <labrea!cascade!mfreeman@decwrl.dec.com>
Subject: ASPLOS-II ADVANCE PROGRAM
SECOND INTERNATIONAL CONFERENCE ON
ARCHITECTURAL SUPPORT FOR PROGRAMMING LANGUAGES
AND OPERATING SYSTEMS
(ASPLOS-II)
Palo Alto, California, October 5-8, 1987
Sponsored by ACM and Computer Society of the IEEE
CONFERENCE CHAIRMEN
General: Martin Freeman, Stanford University & Philips
Research Labs
Program: Randy Katz, U.C. Berkeley
Finance: Dennis Reinhardt, DAIR Computer Systems
Publicity: Jim Flournoy, Consultant
Monday, October 5
08:00-09:00 Tutorial Registration
09:00-12:00 Tutorial I: CACHE MEMORIES, Alan Smith, U.C. Berkeley
Survey of design considerations for cache memories
including recent material on cache workloads, cache
miss ratios, and cache consistency algorithms.
12:00-01:00 LUNCH
01:00-04:00 Tutorial II: RISC ARCHITECTURES: PRINCIPLES & EXAMPLES,
John Hennessy, Stanford University
Survey of the principles behind the RISC approach using
research and commercial machines to illustrate design
tradeoffs.
Tuesday, October 6
08:00-09:00 Conference Registration
09:00-10:00 KEYNOTE SPEAKER: Niklaus Wirth, ETH
"Hardware Architectures for Programming Languages, and
Programming Languages for Hardware Architectures"
10:00-10:30 BREAK
10:30-12:00 SESSION I: OPERATING SYSTEMS, Chair: Forest Baskett,
Silicon Graphics
"VLSI Assist in Building a Multiprocessor Operating
System," B. Beck, B. Kasten, S. Thakkar, Sequent
Computer Systems
"Architectural Support for Multilanguage Parallel
Programming on Heterogeneous Systems," R. Bisiani,
A. Forin, Carnegie-Mellon University
"Machine-Independent Virtual Memory Management for
Paged Uniprocessor and Multiprocessor Architectures,"
R. Rashid, A. Tevanian, M. Young, D. Golub, R. Baron,
D. Black, W. Bolosky, J. Chew, Carnegie-Mellon
University
12:00-01:00 LUNCH
01:00-03:10 SESSION II: LANGUAGES AND INSTRUCTION SETS, Chair:
Chuck Thacker, DEC Systems Research Lab
"An Architecture for the Direct Execution of the
FORTH Programming Language," J. Hayes, M. Fraeman,
R. Williams, T. Zaremba, The Johns Hopkins University
Applied Physics Lab
"Tags and Type Checking in LISP: Hardware and Software
Approaches," P. Steenkiste, J. Hennessy, Stanford
University
"The Effect of Instruction Set Complexity on Program
Size and Memory Performance," J. Davidson, R. Vaughn,
U. of Virginia
"The DRAGON Processor," R. Atkinson, E. McCreight,
Xerox PARC
03:10-03:40 BREAK
03:40-05:00 SESSION III: MISCELLANEOUS ARCHITECTURAL SUPPORT,
Chair: David Ditzel, Sun Microsystems
"Coherency for Multiprocessor Virtual Address Caches,"
J. Goodman, U. of Wisconsin
"Cheap Hardware Support for Software Debugging and
Profiling," T. Cargill, B. Locanthi, AT&T Bell Labs
"An Experimental Coprocessor for Implementing
Persistent Objects on an IBM 4381," C. Georgiou,
S. Palmer, P. Rosenfeld, IBM T.J. Watson Research
Center
Wednesday, October 7
09:10-10:20 SESSION IV: COMPILERS I, Chair: John Hennessy,
Stanford University
"Integer Multiplication and Division on the HP
Precision Architecture," D. Magenheimer, L. Peters,
K. Pettis, D. Zuras, Hewlett-Packard
"The Mahler Experience: Using an Intermediate
Language as a Machine Description," D. Wall,
M. Powell, DEC Western Research Lab
"A Study of Scalar Compilation Techniques for
Pipelined Supercomputers," S. Weiss, J. E. Smith,
MCC
10:20-10:50 BREAK
10:50-12:00 SESSION V: COMPILERS II, Chair: Steven Muchnick,
Sun Microsystems
"Compiling Smalltalk-80 to a RISC," W. Bush,
A. Samples, D. Ungar, P. Hilfinger, U.C. Berkeley
"How Many Addressing Modes are Enough?," F. Chow,
S. Correll, M. Himelstein, E. Killian, L. Weber,
MIPS Computer Systems
"Superoptimizer--A Look at the Smallest Program,"
H. Massalin, Columbia University
12:00-01:30 LUNCH
01:30-03:00 SESSION VI: FUNCTIONAL & LOGIC LANGUAGES, Chair:
Randy Katz, U.C. Berkeley
"Performance and Architectural Evaluation of the
PSI Machine," H. Nakashima, K. Taki, K. Nakajima,
ICOT
"RISCS or CISCs for Prolog: A Case Study,"
G. Borriello, A. Cherenson, P. Danzig, M. Nelson,
U.C. Berkeley
"A RISC Architecture for Symbolic Computation,"
R.B. Kieburtz, Oregon Graduate Center
03:00-03:30 BREAK
03:30-04:40 SESSION VII: NEW MACHINES I, Chair: Jim Goodman,
U. of Wisconsin
"Design Tradeoffs to Support the C Programming
Language in the CRISP Microprocessor,"
D. Ditzel, Sun Microsystems, H. McLellan,
A. Berenbaum, AT&T Bell Labs
"Firefly: A Multiprocessor Workstation," C. Thacker,
L. Stewart, DEC Systems Research Center
"Pipelining and Performance in the VAX 8800 Processor,"
D. Clark, DEC
08:00-10:00 PANEL SESSION: COMPILER SCHEDULED ARCHITECTURES:
HORIZONTAL AND VERTICAL ORGANIZATIONS,
Organizer: Martin Freeman, Stanford University & Philips
Research Labs,
Panelists: Steven Muchnick, Sun Microsystems, Mike Johnson,
AMD, Joseph Fisher, Multiflow, Bob Rau, Cydrome.
Thursday, October 8
08:40-10:00 SESSION VIII: NEW MACHINES II, Chair: E. M. McCreight,
Xerox PARC
"A VLIW Architecture for a Trace Scheduling Compiler,"
R. Colwell, R. Nix, J. O'Donnell, D. Papworth, P. Rodman,
Multiflow Computer Inc.
"Parallel Computers for Graphics Applications," A. Leventhal,
M. Paquette, J. Lawson, P. Hanrahan, PIXAR, Inc.
"The ZS-1 Processor," J.E. Smith, G. Dermer, B. Vanderwarn,
S. Klinger, C. Rozewski, D. Fowler, K. Skidmore, J. Laudon,
Astronautics Corporation of America
10:00-10:30 BREAK
10:30-12:00 PANEL SESSION: LIES, DAMNED LIES, AND BENCHMARKS,
Organizer: Alan Smith, U.C. Berkeley,
Panelists: Jim Gray, Tandem, Harry Nelson, Lawrence
Livermore Labs, Forest Baskett, Silicon Graphics,
Doug Clark, DEC Hudson, John Hennessy, Stanford University
REGISTRATION
Conference registration includes one copy of the proceedings, lunches,
breaks, etc. Tutorial registration covers both tutorials and includes
one copy of the notes for each tutorial, a lunch, and breaks. Student
registration does not include meals. For further information contact
Martin Freeman, (415) 725-3633, mfreeman@sierra.stanford.edu.
ASPLOS REGISTRATION FORM
NAME:..................................................................
Affiliation:...........................................................
Address:...............................................................
.......................................................................
Phone No.:.............................................................
ACM No.:...............................................................
IEEE No.:..............................................................
(Before Sept 5) Member Non-Member Student
Symposium __$185 __$235 __$ 75
Tutorial __$150 __$200 __$ 50
(After Sept 5) Member Non-Member Student
Symposium __$235 __$295 __$100
Tutorial __$200 __$250 __$ 75
__Check Drawn on US Bank Payable To:
ASPLOS-II
3440 Kenneth Drive
Palo Alto, CA 94303 USA
__Master Card __VISA
Card No.:............................................................
Expiration Date:.....................................................
Name on Card:........................................................
Signature:...........................................................
------------------------------
End of PROLOG Digest
********************
∂15-Sep-87 0424 MATHIS@ADA20.ISI.EDU report on ISO NWI and SC22 meeting
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 15 Sep 87 04:24:36 PDT
Date: 14 Sep 1987 19:53-PDT
Sender: MATHIS@ADA20.ISI.EDU
Subject: report on ISO NWI and SC22 meeting
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Cc: Mathis@ADA20.ISI.EDU
Message-ID: <[ADA20.ISI.EDU]14-Sep-87 19:53:33.MATHIS>
At our meeting in Boston in July, the proposed New Work Item for an
international standard for Lisp was discussed. After a mail ballot of the
membership, it was decided (and subsequently endorsed by X3, the parent
committee of X3J13 and the organization responsible for the final US vote on
this issue) to forward the following comments with our ballot:
In the US there is a very strong feeling that "Lisp" is the
name of a family of languages and that it is appropriate to
standardize only on a particular dialect and that the name
of this dialect must be part of the name of the standard. A
name like "ISO Lisp 89" would be too broad and would not
answer the concerns expressed here. Within the Lisp family,
there have existed many popular dialects with fundamental
differences in their design, implementation, and use. While
some of these existing differences may be resolved, others
will certainly appear since the Lisp family encourages such
experimentation and development.
The US concern about the name for the resulting ISO standard
and the wording of this proposed new work item is not a
shallow comment about words only, but is an indication of
our deep concern that the goals and objectives of developing
a standard within the Lisp family should not interfere with
continued developments in other parts of the Lisp family of
languages. This is one of the first issues that must be
considered by an ISO working group resulting from the
approval of this new work item. This naming issue was also
raised as part of the report of the SC22 ad hoc working
group (ISO/TC97/SC22 N 266) that lead to this NWI proposal.
The US feels that report should be one of the initial
documents of the working group resulting from this NWI
proposal and that the various issues it raises be addressed.
Other countries have also submitted comments -- France offered a Convenor,
Japan thought there should be more emphasis on Common Lisp, and the United
Kingdom emphasized the need for a single standard.
ISO/IEC JTC1/SC22 (the SubCommittee on Languages of Joint Technical Committee
1 of the International Organization for Standardization and the International
Electrotechnical Commission) decided to form Working Group 16 on Lisp.
Christian Queinnic was named Convenor and Richard Gabriel and William Klinger
were named as project editors.
At that same meeting there was considerable discussion about the handling of
large character sets in programming languages. While this issue is frequently
thought of in terms of handling Japanese and Chinese, it is also important for
European languages other than English and for modern text manipulation
systems.
The first meeting of WG 16 will be held February 24 and 25, 1988, in Paris,
France. There will be an International Workshop on Lisp Evolution and
Standardization on February 22 and 23, also in Paris. Participation in the
Workshop is separate from participation in the ISO/IEC Working Group.
∂15-Sep-87 0744 @Sushi.Stanford.EDU:brassard%cwi.nl@forsythe.stanford.edu For Number Theory Net
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 15 Sep 87 07:44:50 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 15 Sep 87 07:37:18-PDT
Received: by lindy.stanford.edu; Tue, 15 Sep 87 07:40:51 PDT
Resent-From: brassard%cwi.nl@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Tue, 15 Sep 87 07:39:37 PDT
Date: Mon, 14 Sep 87 11:48:03 +0200
From: brassard%cwi.nl@forsythe.stanford.edu (Gilles Brassard)
Subject: For Number Theory Net
Message-Id: <C099.THEORYNT@ibm.com>
Resent-Date: 15 Sep 1987 10:39:42-EDT (Tuesday)
Resent-Sender: THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Resent-To: aflb.tn@sushi.stanford.edu
Apparently-To: aflb.tn@sushi.stanford.edu
TEMPORARY CHANGE OF ADDRESS
I am spending this fall term at the CWI, Amsterdam.
Give me a call if you come by ! office: 592-4059
home: 24.70.58
brassard@zuring.cwi.nl
∂15-Sep-87 0857 @Sushi.Stanford.EDU:steve%hubcap.clemson.edu@forsythe.stanford.edu Request for suggestions in developing theory course
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 15 Sep 87 08:47:41 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 15 Sep 87 08:39:16-PDT
Received: by lindy.stanford.edu; Tue, 15 Sep 87 08:42:49 PDT
Resent-From: steve%hubcap.clemson.edu@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Tue, 15 Sep 87 08:41:40 PDT
Date: Tue, 15 Sep 87 11:23:01 edt
From: "Steve" Stevenson <steve%hubcap.clemson.edu@forsythe.stanford.edu>
Subject: Request for suggestions in developing theory course
Message-Id: <C100.THEORYNT@ibm.com>
Resent-Date: 15 Sep 1987 11:41:49-EDT (Tuesday)
Resent-Sender: THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Resent-To: aflb.tn@sushi.stanford.edu
Apparently-To: aflb.tn@sushi.stanford.edu
I am trying to put together a junior level class that would serve as a
basis for later computability and compiler classes. I would like some
help identifying the exact KNOWLEDGE that a junior should have when entring
the later classes (both of which are electives) and what SKILLS I should
assume/develop. The subject class would be required of all CS folks.
Please send suggestions to me and I summarize:
(1) (c) Ten theorems/facts that every computer scientist should know.
(e.g., Kleene's theorem, pumping lemma for context-free,...)
(2) (c) Ten canonical problems every computer scientist should know
(e.g., halting problem, busy beaver,...).
(3) Proof techniques to emphasize.
(4) Suggestions concerning topics.
Steve (really "D. E.") Stevenson steve@hubcap.clemson.edu
Department of Computer Science, (803)656-5880.mabell
Clemson University, Clemson, SC 29634-1906
∂15-Sep-87 0929 dcm%hpfclp@hplabs.HP.COM October X3J13 meeting
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 15 Sep 87 09:28:34 PDT
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Tue, 15 Sep 87 10:27:15 mdt
Received: from hpfcdcm by hpfcdcm.HP.COM; Tue, 15 Sep 87 10:27:41 mdt
Return-Path: <dcm@hpfcdcm>
Message-Id: <8709151627.AA15748@hpfcdcm.HP.COM>
To: x3j13@sail.stanford.edu
Cc: mathix@ada20.isi.edu
Subject: October X3J13 meeting
From: Dave_Matthews%hpfclp@hplabs.HP.COM
X-Mailer: mh6.5
Date: Tue, 15 Sep 87 10:27:37 MST
Sender: dcm%hpfclp@hplabs.HP.COM
X3J13 Meeting
10/20/87 - 10/21/87
Fort Collins, Colorado
The fifth meeting of X3J13 will be held Monday through Wednesday,
October 19-21 at the University Park Holiday Inn in Fort Collins,
Colorado. Monday has been set aside for committee meetings, followed
by the main meeting on Tuesday and Wednesday. October is the perfect
time to see fall (and sometimes winter) in Colorado. Rocky Mountain
National Park is approximately one hour from Fort Collins.
Hewlett-Packard's travel affiliate, Lifeco Travel, has negotiated
discount airfares that you can obtain by calling:
800-521-8858 (in California)
800-722-8755 (elsewhere)
Ask to make a group reservation for X3J13. You may also make your
room, rental car, or airport limousine reservations through Lifeco at
the same time. Payment must be made by credit card. Tickets will be
mailed via registered mail. Late reservations can be express mailed
at additional cost.
A block of rooms is available at the University Park Holiday Inn at
$46.50 plus tax per night. If you don't make reservations through
Lifeco Travel, please make your own reservations by calling
(303)482-2626 and asking to reserve a room in the "HP X3J13" block.
Reservations will be held until 6 PM unless guaranteed by a major
credit card. Non-smoking rooms are available. Check-in and check-out
times are 1 PM. The block of rooms will be dropped on 10/2/87, but
you should still be able to obtain the discounted room rate on
available rooms if you specify you are attending the the "HP X3J13"
conference.
Refreshments and lunch are being arranged for Tuesday and Wednesday.
I expect these arrangements will run $50 or less per person which I
will collect at the meeting. I should be able to update this value in
a few weeks. Please note any dietary restrictions so I can make the
necessary arrangements with the catering department.
If there is sufficient interest I would like to arrange a dinner
Tuesday evening at Cuisine, Cuisine. Cuisine, Cuisine is an intimate
cafe offering some the best and most unusual food in Northern
Colorado. It is a very small cafe which can only accommodate 60 total
patrons, but they are willing to put together a special banquet for
us. To handle a group this large in a short period of time they would
like to limit the menu to 4 items. The list of possible entrees
includes: Cajun roast duckling with spice peach gravy, chicken boursin
(double breast of chicken stuffed with herbed cream cheese dressing
and mushroom voloute' sauce), shrimp diane (sauteed jumbo shrimp in a
garlic cajun sauce), sirloin tips with mushrooms and onions, poached
salmon with a special sauce, or boned leg of lamb stuffed with spinach
and served with a dijon sauce. A vegetarian entree will also be
available. Entrees would be about 15 dollars, including soup or
salad. Appetizers, dessert, and beverage would be ala carte.
Cuisine, Cuisine accepts charge cards, but cash would also be welcome.
I would need to narrow this to the four items at least 2 weeks in
advance so they could make the necessary preparations. Note if you
are interested on the registration form and mark your first and second
choice entrees. Please note any dietary restrictions if this
selection is not sufficient.
Fort Collins is approximately a one hour drive from Denver's Stapleton
International Airport. From the airport take I-270 or I-70 west to
I-25 and go north on I-25 towards Cheyenne, Wyoming. Take the first
Fort Collins exit, #265, turn left and drive 5 miles to the College
Avenue intersection. Turn right and drive 3 miles to the Prospect
Road intersection. Turn left and the Holiday Inn is just across the
railroad tracks on the south side of the road. It shouldn't be hard
to see since it is 8 stories tall in an area with very few building
over 2 stories.
Two limousine services provide shuttle service from Stapleton directly
to the Holiday Inn. Fort Collins Express (303-482-0505) leaves
Stapleton on the hour while the Front Range Airporter (303-221-5466)
leaves Stapleton on the half hour. Both are located in the baggage
claim area. The charge is $12 each way on the Express and $13 on the
Airporter.
| Prospect Road ||
=========|====================== ||
HI | ||
M | ||
O | ||
U | ||
N | Drake Road North ||
T =========|====================== /\ ||
A | || ||
I |US 287/ College Avenue ||
N | ||I-25
S | ||
| Horsetooth Road ||
=========|====================== ||
| ||
| ||
| ||
| ||
| Harmony Road HP /||\
=========|=============================================||===========
| \||/ Exit 265
| ||
||
\/
Denver
Please return the following registration form by October 5 via
electronic mail to dcm%hpfclp@hplabs.hp.com or via US Mail to:
Dave Matthews
Hewlett-Packard Company
3404 E Harmony Road
Fort Collins, Colorado 80525
(303)339-2201
Feel free to contact me if you have any questions
__________________________________________________________________________
X3J13 OCTOBER MEETING REGISTRATION FORM
Name: __________________________________________________
Institution: __________________________________________________
Street Address: __________________________________________________
City, State, Zip: __________________________________________________
Phone: __________________________________________________
Network Address: __________________________________________________
Dinner 10/20 (y/n): __________________________________________________
First choice: __________________________________________________
Second choice: __________________________________________________
(Duck, chicken, shrimp, sirloin, salmon, lamb, vegetarian)
Dietary Restrictions: __________________________________________________
__________________________________________________
__________________________________________________
∂16-Sep-87 0102 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #60
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Sep 87 01:02:50 PDT
Date: Tue 15 Sep 1987 13:06-PDT
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #60
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Wednesday, 16 Sep 1987 Volume 5 : Issue 60
Today's Topics:
Query - Goal Stack,
LP Library - Request
----------------------------------------------------------------------
Date: 14 Sep 87 20:37:00 GMT
From: meth@nyu.csd2.edu or meth@nyu-csd2.arpa
Subject: goal-stack accessible?
Is the goal-stack, in Prolog, stored in an accessible place & form?
i.e., If I wish to check the list of goals that are on the stack,
still being attempted to be satisfied, (in reverse order of their
appearance), is this structure available to me ?
Thank you.
-- Asher Meth
------------------------------
Date: Tue, 25 Aug 87 22:06:07 EDT
From: Bruce T. Smith <bts@cs.duke.edu>
Subject: List-of-Prologs
I am trying to get the List-of-Prologs up to date, again. I have
posted an old copy to USENET's comp.lang.prolog, and several folks
have already responded.
Please send info on new Prolog (or other logic programming)
systems, as well as updates to old ones, to me at UNC-CH, either by
email or hardcopy.
As always, I'm interested in all logic programming systems,
from the "send a tape and $20" up to the expensive commercial stuff.
However, most readers of these newsgroups/lists are in academia, so
please let us know if you give discounts. And, don't be ashamed to
tell us about experimental systems you're working on.
-- Bruce T. Smith
------------------------------
End of PROLOG Digest
********************
∂16-Sep-87 0920 TOM@score.stanford.edu campus power shutdown ll
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Sep 87 09:19:55 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Wed, 16 Sep 87 09:16:50 PDT
Date: Wed 16 Sep 87 09:14:44-PDT
From: Thomas Dienstbier <TOM@score.stanford.edu>
Subject: campus power shutdown ll
To: csd@score.stanford.edu, faculty@score.stanford.edu
Message-Id: <12335101220.11.TOM@Score.Stanford.EDU>
This weekend there will be a campus wide power shutdown. This time
it will be on both Saturday and Sunday from the hours 0700 thru 1200.
ALL MJH COMPUTERS WILL BE DOWN FOR THE DURATION, FROM SATURDAY 0700
thru SUNDAY 1200.
We plan on bringing up mostly netrworking style systems(tips,gateways,IMP,etc).
Our experience with last Saturdays power shut down was not good. We still
have some machines down that are awaiting parts, so that they may be brought
back up.
By remaining down for the hours mentioned, we would expect to eliminate some
of the problems that would/could occur.
As again, please make sure that your equipment in your offices are power
off.
Also rumor has it, nothing official, that in December we will experience
one more power outage, lasting 12 hours.
tom
-------
∂16-Sep-87 1145 dcm%hpfclp@hplabs.HP.COM November X3J13 meeting
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 16 Sep 87 11:45:10 PDT
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Wed, 16 Sep 87 12:43:25 mdt
Received: from hpfcdcm by hpfcdcm.HP.COM; Wed, 16 Sep 87 12:43:23 mdt
Return-Path: <dcm@hpfcdcm>
To: x3j13@sail.stanford.edu
Cc: mathis@ada20.isi.edu, dcm%hpfcdcm@hplabs.HP.COM
Subject: November X3J13 meeting
From: Dave_Matthews%hpfclp@hplabs.HP.COM
X-Mailer: mh6.5
Date: Wed, 16 Sep 87 12:43:19 MST
Message-Id: <1297.558816199@hpfcdcm>
Sender: dcm%hpfclp@hplabs.HP.COM
Bob Mathis requested that I delay the meeting a month so the subcommittees
will have more time to prepare their reports. I have rescheduled the
meeting a month later, November 16-18, which seemed to be the most
desirable dates in November. Other than the date changes there are no
other changes in the arrangements.
Dave Matthews
--------------------------------------------------------------------------
X3J13 Meeting
11/16/87 - 11/18/87
Fort Collins, Colorado
The fifth meeting of X3J13 will be held Monday through Wednesday, November
16-18 at the University Park Holiday Inn in Fort Collins, Colorado. Monday
has been set aside for committee meetings, followed by the main meeting on
Tuesday and Wednesday. November is the perfect time to see fall (and
sometimes winter) in Colorado. Rocky Mountain National Park is
approximately one hour from Fort Collins.
Hewlett-Packard's travel affiliate, Lifeco Travel, has negotiated discount
airfares that you can obtain by calling:
800-521-8858 (in California)
800-722-8755 (elsewhere)
Ask to make a group reservation for X3J13. You may also make your room,
rental car, or airport limousine reservations through Lifeco at the same
time. Payment must be made by credit card. Tickets will be mailed via
registered mail. Late reservations can be express mailed at additional
cost.
A block of rooms is available at the University Park Holiday Inn at $46.50
plus tax per night. If you don't make reservations through Lifeco Travel,
please make your own reservations by calling (303)482-2626 and asking to
reserve a room in the "HP X3J13" block. Reservations will be held until 6
PM unless guaranteed by a major credit card. Non-smoking rooms are
available. Check-in and check-out times are 1 PM. The block of rooms will
be dropped on 11/2/87, but you should still be able to obtain the
discounted room rate on available rooms if you specify you are attending
the the "HP X3J13" conference.
Refreshments and lunch are being arranged for Tuesday and Wednesday. I
expect these arrangements will run $50 or less per person which I will
collect at the meeting. I should be able to update this value in a few
weeks. Please note any dietary restrictions so I can make the necessary
arrangements with the catering department.
If there is sufficient interest I would like to arrange a dinner Tuesday
evening at Cuisine, Cuisine. Cuisine, Cuisine is an intimate cafe offering
some the best and most unusual food in Northern Colorado. It is a very
small cafe which can only accommodate 60 total patrons, but they are
willing to put together a special banquet for us. To handle a group this
large in a short period of time they would like to limit the menu to 4
items. The list of possible entrees includes: Cajun roast duckling with
spice peach gravy, chicken boursin (double breast of chicken stuffed with
herbed cream cheese dressing and mushroom voloute' sauce), shrimp diane
(sauteed jumbo shrimp in a garlic cajun sauce), sirloin tips with mushrooms
and onions, poached salmon with a special sauce, or boned leg of lamb
stuffed with spinach and served with a dijon sauce. A vegetarian entree
will also be available. Entrees would be about 15 dollars, including soup
or salad. Appetizers, dessert, and beverage would be ala carte. Cuisine,
Cuisine accepts charge cards, but cash would also be welcome.
I would need to narrow this to the four items at least 2 weeks in advance
so they could make the necessary preparations. Note if you are interested
on the registration form and mark your first and second choice entrees.
Please note any dietary restrictions if this selection is not sufficient.
Fort Collins is approximately a one hour drive from Denver's Stapleton
International Airport. From the airport take I-270 or I-70 west to I-25
and go north on I-25 towards Cheyenne, Wyoming. Take the first Fort
Collins exit, #265, turn left and drive 5 miles to the College Avenue
intersection. Turn right and drive 3 miles to the Prospect Road
intersection. Turn left and the Holiday Inn is just across the railroad
tracks on the south side of the road. It shouldn't be hard to see since it
is 8 stories tall in an area with very few building over 2 stories.
Two limousine services provide shuttle service from Stapleton directly to
the Holiday Inn. Fort Collins Express (303-482-0505) leaves Stapleton on
the hour while the Front Range Airporter (303-221-5466) leaves Stapleton on
the half hour. Both are located in the baggage claim area. The charge is
$12 each way on the Express and $13 on the Airporter.
| Prospect Road ||
=========|====================== ||
HI | ||
M | ||
O | ||
U | ||
N | Drake Road North ||
T =========|====================== /\ ||
A | || ||
I |US 287/ College Avenue ||
N | ||I-25
S | ||
| Horsetooth Road ||
=========|====================== ||
| ||
| ||
| ||
| ||
| Harmony Road HP /||\
=========|=============================================||===========
| \||/ Exit 265
| ||
||
\/
Denver
Please return the following registration form by November 2 via electronic
mail to dcm%hpfclp@hplabs.hp.com or via US Mail to:
Dave Matthews
Hewlett-Packard Company
3404 E Harmony Road
Fort Collins, Colorado 80525
(303)339-2201
Feel free to contact me if you have any questions.
__________________________________________________________________________
X3J13 NOVEMBER MEETING REGISTRATION FORM
Name: __________________________________________________
Institution: __________________________________________________
Street Address: __________________________________________________
City, State, Zip: __________________________________________________
Phone: __________________________________________________
Network Address: __________________________________________________
Dinner 11/17 (y/n): __________________________________________________
First choice: __________________________________________________
Second choice: __________________________________________________
(Duck, chicken, shrimp, sirloin, salmon, lamb, vegetarian)
Dietary Restrictions: __________________________________________________
__________________________________________________
__________________________________________________
∂16-Sep-87 1748 SLOAN@score.stanford.edu 1987-88 Faculty Staff Directory
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Sep 87 17:48:07 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Wed, 16 Sep 87 17:43:48 PDT
Date: Wed 16 Sep 87 17:10:19-PDT
From: Yvette Sloan <SLOAN@score.stanford.edu>
Subject: 1987-88 Faculty Staff Directory
To: Faculty@score.stanford.edu, Staff@score.stanford.edu,
Sec@score.stanford.edu
Message-Id: <12335187798.32.SLOAN@Score.Stanford.EDU>
It is time to update the Faculty/Staff Directory for AY 87/88. Please stop
by my office (MJH 260) and check the list to see that your information is
correct. So as not to spend an entire day (or several entire days) on this,
I would appreciate it if you would come between the hours of 2:00 - 4:00 p.m.
If I don't hear from you by *Wednesday, September 23*, I will assume that
your information is correct.
Thanks.
-----Yvette
-------
∂16-Sep-87 1818 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com NEXT WEEK'S PLANLUNCH -- Sanjay Mittal
Received: from WARBUCKS.AI.SRI.COM by SAIL.STANFORD.EDU with TCP; 16 Sep 87 18:18:38 PDT
Received: from venice by WARBUCKS.AI.SRI.COM via SMTP with TCP; Wed,
16 Sep 87 18:11:29-PDT
Received: by venice (3.2/4.16) id AA17493 for
planlunch@warbucks.ai.sri.com; Wed, 16 Sep 87 18:15:21 PDT
Date: Wed, 16 Sep 87 18:15:21 PDT
From: Amy Lansky <lansky@venice.ai.sri.com>
Message-Id: <8709170115.AA17493@venice>
To: planlunch@warbucks.ai.sri.com
Subject: NEXT WEEK'S PLANLUNCH -- Sanjay Mittal
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
PRIDE: A KNOWLEDGE-BASED FRAMEWORK FOR DESIGN
Sanjay Mittal (MITTAL@XEROX.COM)
Intelligent Systems Laboratory, Xerox PARC
11:00 AM, MONDAY, September 21
SRI International, Building E, Room EJ228
In this talk I will describe the Pride project at Xerox. The first
part of the talk will be about an expert system for the design of
paper transports inside copiers. A prototype version of the system has
been in field test for over a year and will be in regular use by
year-end. It has been successfully used on real copier projects inside
Xerox - both for designing and for checking designs produced by
engineers. From an applications point of view we have been motivated
by the following observations: knowledge is often distributed among
different experts; the process of generating designs is unnecessarily
separated from their analysis, leading to long design cycles; and
design is an evolutionary process, i.e., a process of exploration.
The second part of the talk will describe the framework in Pride for
representing design knowledge and using it to support the design
process. In this framework, called Describe, the process of designing
an artifact is viewed as knowledge guided search in a
multi-dimensional space of possible designs. The dimensions of such a
space are the design parameters of the artifact. In this view,
knowledge is used not only to search the space but also to define the
space. Domain knowledge is organized in terms of design plans, which
are organized around goals. Conceptually, goals decompose a problem
into sub-problems and are the units for structuring knowledge. Design
goals have design methods associated with them, which specify
alternate ways to make decisions about the design parameters of the
goal. The third major element of a plan are constraints on the design
parameters. The framework provides a problem solver for executing
these plans. The problem solver combines dependency-directed
backtracking ideas with an advice mechanism and a context mechanism
for simultaneously maintaining multiple partial designs. The Describe
framework has been successfully used to build a second expert system
called Cossack for configuring micro-computer systems.
If time permits, I will talk about some of the more recent ideas that
have come out of the Pride project: Knowledge compilation, Partial
choices in constraint reasoning, and constraint compilation.
∂17-Sep-87 0834 TAJNAI@score.stanford.edu Reminder! Sunrise Club Breakfast Tuesday, 9/22
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Sep 87 08:34:39 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Thu, 17 Sep 87 08:32:20 PDT
Date: Thu 17 Sep 87 08:30:15-PDT
From: Carolyn Tajnai <TAJNAI@score.stanford.edu>
Subject: Reminder! Sunrise Club Breakfast Tuesday, 9/22
To: faculty@score.stanford.edu
Message-Id: <12335355267.20.TAJNAI@Score.Stanford.EDU>
If you have not done so, please RSVP for the Sunrise Club Breakfast
scheduled for
Tuesday morning, Sept. 22, 7:30 - 9 a.m.,
Tresidder.
Professor M.R. Beasley will be giving a special presentation on
"New Advances in Superconductivity".
Jim Gibbons is hoping for a BIG turnout.
Carolyn
-------
∂17-Sep-87 1624 CBARSALOU@Score.Stanford.EDU Dr. Lawvere's visit: talks
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Sep 87 16:24:43 PDT
Date: Thu 17 Sep 87 16:16:47-PDT
From: Caroline Barsalou <CBARSALOU@Score.Stanford.EDU>
Subject: Dr. Lawvere's visit: talks
To: colloq@Score.Stanford.EDU, conmod@Navajo.Stanford.EDU,
logic@CSLI.Stanford.EDU, logmtc@Sail.Stanford.EDU
Message-ID: <12335440196.39.CBARSALOU@Score.Stanford.EDU>
Subject: Lawvere visit
Bill Lawvere will visit Stanford during Sept 23-28. He will present
recent work of his own, and will interact with some of us involved
in applications of category theory to computer science problems.
Over the past seventeen years Lawvere has had a considerable influence
on the direction taken by category theory research. Among his better
known contributions are topos theory, algebraic theories, and
hyperdoctrines.
Lawvere will give two talks, at times and places to be advertised
at the end of this week.
1. Qualitative Distinctions Between Toposes of Graphs
Reflexive graphs form a topos of motion parametrizers, whereas the
topos of irreflexive graphs corresponds to a single object in the
former topos. Relations with Schutzenberger monoids are also
discussed.
2. Recent Results on Metric Spaces as Enriched Categories.
Categories support a rich family of relations and operations borrowed
from one or another particular category and generalized to all
categories. In this work we generalize certain metric space notions
including radius and geodesic distance.
It is hoped that the interactions may lead to a third talk illuminating
some of the issues in the applications we are interested in.
-------
∂17-Sep-87 2229 @Sushi.Stanford.EDU:ashok%ibm.com@forsythe.stanford.edu FOCS 1987 registration and program
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Sep 87 22:29:50 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Thu 17 Sep 87 22:18:35-PDT
Received: by lindy.stanford.edu; Thu, 17 Sep 87 21:23:08 PDT
Resent-From: ashok%ibm.com@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Thu, 17 Sep 87 21:21:27 PDT
Date: Thu, 17 Sep 87 17:29:22 edt
From: Ashok Chandra <ashok@ibm.com>
Subject: FOCS 1987 registration and program
Message-Id: <C101.THEORYNT@ibm.com>
Resent-Date: 18 Sep 1987 00:16:45-EDT (Friday)
Resent-Sender: THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Resent-To: aflb.tn@sushi.stanford.edu
Apparently-To: aflb.tn@sushi.stanford.edu
FOCS 1987
28th Annual Symposium on Foundations of Computer Science
Los Angeles, California
October 12-14, 1987
REGISTRATION
Use this form or a facsimile to preregister. Advanced registration
material should be sent postmarked by Wednesday, September 23, 1987.
Please make checks payable to "Foundations of Computer Science 1987".
Mail check and completed form to:
Seymour Ginsburg
Foundations of Computer Science 1987
Computer Science Department
University of Southern California
Los Angeles, CA 90089-0782
(Telephone: 213-743-2068)
Mailed by After
Fees(check one) Sept 23, 1987 Sept 23, 1987
Member of IEEE Computer
Society or SIGACT $165 $220
Nonmembers $220 $290
Author or Program Committee
Member $165 $220
Full-time students $50 $60
Name _______________________________________________________
Affiliation ________________________________________________
Address ____________________________________________________
City _______________________ State ________________________
Country _________________________________ Zip ______________
Tel ______________________ Elec. mail _____________________
Dietary restriction: Kosher ___ Vegetarian ___
Request for refund will be honored until October 5, 1987.
HOTEL RESERVATION FORM
Mail to:
FOCS Symposium
Reservations Department
Marina Beach Hotel
4100 Admiralty Way
Marina Del Rey, CA. 90292
(Telephone, Inside Calif: 800-8-MARINA; Outside Calif: 800-882-4000)
Please reserve a room for me at the Foundations of Computer Science
Symposium, October 11-14, 1987.
Single $85 per day
Double(twin) $85 per day
Triple $100 per day
(plus 10% occupancy tax)
Arrival date and time _______________________________________
Departure date ______________________________________________
Please send confirmation to:
Mr./Ms. ________________________________________________________
(Please print full name)
Address ________________________________________________________
City _____________________ State ________________ Zip __________
Country ________________________________________________________
To avoid duplication of reservations, please submit only one form
when sharing rooms.
Names of the others sharing the room:
_________________________________________________________________
_________________________________________________________________
Please be sure your reservation reaches the hotel (or call the
toll-free number) by Sep 21 to ensure your accommodations.
Payment of first night's lodging is required as a deposit - credit
card authorizations will be accepted over the telephone. Refund due
to cancellation will be honored until 72 hours prior to arrival time.
Indicate method of payment:
First night's deposit enclosed ___________
Credit card _______________ #_________________ Exp _______________
Signature ___________________________________________________
Print Name __________________________________________________
CONFERENCE INFORMATION
LOCATION
The conference will be at the Marina Beach Hotel, 4100 Admiralty Way,
Marina Del Rey, CA. 90292. (Telephone, Inside Calif: 800-8-MARINA; Outside
Calif: 800-882-4000.) All technical sessions will be held in the Grand
Ballroom of that hotel.
A block of 300 rooms has been reserved (until Monday, Sept 21) at the
Marina Beach Hotel. 50 additional rooms have been reserved as backup at the
Marina International Hotel (one block away). The price for rooms at both
hotels are the same, namely $85 per night for one or two people, and
$100 for three. Please make reservations directly with the Marina Beach
Hotel.
TRANSPORTATION:
The Marina Beach Hotel is approximately 6 miles north of the Los Angeles
International Airport, in the fashionable Marina Del Rey area of Los
Angeles. Complementary transportation is available for individuals
arriving at the airport; use the courtesy phone in the baggage claim
area to call the hotel. Taxi fare from the airport is about $13. Those
coming by car should take Lincoln Blvd to Bali Way, go left one block,
and then right on Admiralty Way for about a mile to the hotel.
CLIMATE: Weather during the middle of October is usually mild, with just
a slight chance of rain. Daytime temperatures range between 60 degrees F
and 75 degrees F, with slightly cooler evenings.
THINGS TO DO: The marina is the world's largest man-made small craft harbor.
Activities available nearby include sailing, harbor cruises, fishing, and
jogging. A variety of shops and restaurants are located within a mile of the
hotel.
REGISTRATION: Registration for the conference will be located in the foyer
of the hotel, and will be open Sunday (5:00 p.m. - 10:00 p.m.), Monday (8:30
a.m. - 5:00 p.m.), and Tuesday (9:00 a.m. - 12:00 p.m.). Fees are listed
elsewhere in this brochure. The regular registration fee includes technical
sessions, a copy of the proceedings, the Sunday reception, three luncheons,
and the Tuesday evening banquet. The student registration fee does not
include the banquet. Students should bring evidence of student status to the
registration desk.
RECEPTION: A reception will be held Sunday, October 11, from 8:00 p.m. to
11:00 p.m. in the Grand Ballroom of the hotel.
BUSINESS MEETING: There will be a business meeting on Monday evening from
9 p.m. to 10:30 p.m. in the Grand Ballroom. All interested registrants are
invited.
BANQUET: The Banquet will be on Tuesday evening in the Grand Ballroom.
Doors will open at 7:00 p.m.
PROCEEDINGS: A limited number of additional copies of the Symposium
Proceedings will be available for purchase at the registration desk.
ACKNOWLEDGMENTS: Student meals were made possible by a contribution from
the industrial affiliates of SIGACT and TC-MFC.
MACHTEY AWARD: The Machtey Award is presented for the most outstanding
paper written by a student or students, as judged by the program committee.
It includes a grant to help defray authors' expenses in attending the
FOCS Symposium. Please consider a donation to the Machtey Award Fund to
sustain this tradition. All donations should be made payable to the Machtey
Award Fund on a separate check and sent with the regular registration items.
CONFERENCE CREDITS
LOCAL ARRANGEMENTS CHAIR
Seymour Ginsburg (with the assistance of Ming-Deh Huang)
Computer Science Department
University of Southern California
Los Angeles, CA. 90089-0782
(Telephone: 213-743-2068)
CONFERENCE CHAIR
Ashok K Chandra
IBM T.J. Watson Research Center
P.O.Box 218
Yorktown Heights,NY 10598
CONFERENCE SECRETARY
David W Bray
Clarkson College
Educational Computing
Potsdam, N.Y. 13676
SYMPOSIUM COORDINATOR
John C Cherniavsky
Computer Science Department
Georgetown University
Washington, D.C. 20057
PROGRAM COMMITTEE CHAIR
Tom Leighton
Department of Mathematics
Massachussetts Institute of Technology
Cambridge, MA 02139
PROGRAM COMMITTEE
Laszlo Babai Paris Kanellakis
Michael Ben-Or Rao Kosaraju
Michael Fischer Tom Leighton
Shafi Goldwasser Michael Paterson
Leonidas Guibas Robert Tarjan
Joseph Halpern Uzi Vishkin
PROGRAM FOR FOCS '87
MONDAY, OCTOBER 12
Session 1. Chair: Leonidas Guibas
8:30 Polytope range searching and integral geometry
B. Chazelle, Princeton U.
8:50 An output sensitive algorithm for computing visibility graphs
S. Ghosh, U. Maryland
D. Mount, U. Maryland
9:10 Delaunay graphs are almost as good as complete graphs
D. Dobkin, Princeton U.
S. Friedman, Princeton U.
K. Supowit, Princeton U.
9:30 On the lower envelope of bivariate functions and its applications
H. Edelsbrunner, U. Illinois at Urbana
J. Pach, Hungarian Academy of Sciences
J. Schwartz, N.Y.U.
M. Sharir, Tel Aviv U.
9:50 Break
Session 2. Chair: Michael Paterson
10:20 A new algebraic method for robot motion planning and real geometry
J. Canny, M.I.T.
10:40 New lower bound techniques for robot motion planning problems
J. Canny, M.I.T.
J. Reif, Duke U.
11:00 Learning one-counter languages in polynomial time
P. Berman, Penn. State U.
R. Roos, Penn. State U.
11:20 Learning quickly when irrelevant attributes abound: a new linear-
threshold algorithm
N. Littlestone, U.C. Santa Cruz
11:40 Diversity-based inference of finite automata
R. Rivest, M.I.T.
R. Schapire, M.I.T.
12:00 Lunch
Session 3. Chair: Michael Fischer
2:00 Incomparability in parallel computation
V. Grolmusz, U. Chicago and Eotvos U.
P. Ragde, U. Toronto
2:20 Threshold circuits of bounded depth
A. Hajnal, U. Illinois at Chicago and Hungarian Academy of Sciences
W. Maass, U. Illinois at Chicago
P. Pudlak, U. Illinois at Chicago and Czechoslovakian Acad. Sciences
M. Szegedy, U. Chicago
G. Turan, U. Illinois at Chicago and Hungarian Academy of Sciences
3:00 Complete and incomplete randomized NP problems
Y. Gurevich, U. Michigan
3:20 Generic oracles and oracle classes
M. Blum, U.C. Berkeley
R. Impagliazzo, U.C. Berkeley
3:40 Break
Session 4. Chair: Michael Ben-Or
4:10 Polynomial decomposition algorithms
D. Kozen, Cornell U.
S. Landau, Wesleyan U.
J. von zur Gathen, U. Toronto
4:30 Factoring polynomials over finite fields
L. Ronyai, Hungarian Academy of Sciences and U. Chicago
4:50 Multiplicative complexity of polynomial multiplication over finite
fields
M. Kaminski, Technion
N. Bshouty, Technion
5:10 The multiplicative complexity of Boolean quadratic forms
R. Mirwald, U. Frankfurt
C. Schnorr, U. Frankfurt
5:30 Break
9:00 Business Meeting
TUESDAY, OCTOBER 13
Session 5. Chair: Uzi Vishkin
8:30 Cascading divide-and-conquer: a technique for designing parallel
algorithms
M. Atallah, Purdue U.
R. Cole, N.Y.U.
M. Goodrich, Purdue U.
8:50 A new parallel algorithm for the maximal independent set problem
M. Goldberg, R.P.I.
T. Spencer, R.P.I.
9:10 The matching problem for bipartite graphs with polynomially
bounded permanents is in NC
D. Grigoriev, Soviet Academy of Sciences
M. Karpinski, U. Bonn
9:30 On the complexity of some computations with polynomials and
Toeplitz matrices
V. Pan, S.U.N.Y. Albany
J. Reif, Duke U.
9:50 Break
Session 6. Chair: Tom Leighton
10:20 How to emulate shared memory
A. Ranade, Yale U.
10:40 A lower bound of Omega(log log n) for randomized parallel merging
M. Gereb-Graus, Harvard U.
D. Krizanc, Harvard U.
11:00 The average complexity of deterministic and randomized parallel
comparison sorting algorithms
N. Alon, Tel Aviv U.
Y. Azar, Tel Aviv U.
11:20 Hierarchical memory with block transfer
A. Aggarwal, I.B.M. Watson Research Center
A. Chandra, I.B.M. Watson Research Center
M. Snir, I.B.M. Watson Research Center
11:40 Approximation algorithms for scheduling unrelated parallel
machines
J. Lenstra, C.W.I.
D. Shmoys, M.I.T.
E. Tardos, Eotvos U.
12:00 Lunch
Session 7. Chair: Robert Tarjan
2:00 Finding near optimal separators in planar graphs
S. Rao, M.I.T.
2:20 A parallel algorithm for finding a separator in planar graphs
H. Gazit, U. Southern California
G. Miller, U. Southern California
2:40 Determining edge connectivity in O(nm) steps
D. Matula, Southern Methodist U.
3:00 Improved algorithms for graph four-connectivity
A. Kanevsky, U. Illinois at Urbana
V. Ramachandran, U. Illinois at Urbana
3:20 Parallel graph algorithms that are efficient on average
D. Coppersmith, I.B.M. Watson Research Center
P. Raghavan, I.B.M. Watson Research Center
M. Tompa, I.B.M. Watson Research Center
3:40 Break
Session 8. Chair: Laszlo Babai
4:10 Canonical labeling of regular graphs in linear average time
L. Kucera, U. Chicago and Charles U.
4:30 Eigenvalues and graph bisection: an average-case analysis
R. Boppana, M.I.T.
4:50 On the second eigenvalue of random regular graphs
A. Broder, D.E.C.-S.R.C.
E. Shamir, D.E.C.-S.R.C. and U. Chicago
5:10 Recursive construction for 3-regular expanders
M. Ajtai, I.B.M. Almaden Research Center
5:30 Break
7:00 Banquet
WEDNESDAY, OCTOBER 14
Session 9. Chair: Rao Kosaraju
8:30 The organization of permutation architectures with bussed
interconnections
J. Kilian, M.I.T.
S. Kipnis, M.I.T.
C. Leiserson, M.I.T.
8:50 Channel routing of multiterminal nets
S. Gao, U. Saarlandes
M. Kaufmann, U. Saarlandes
9:10 Two lower bounds in asynchronous distributed computation
P. Duris, Slovak Academy Sciences
Z. Galil, Columbia U.
9:30 Locality as an obstacle to distributed computing
N. Linial, Hebrew U.
9:50 Break
Session 10. Chair: Paris Kanellakis
10:20 Achievable cases in an asynchronous environment
H. Attiya, Hebrew U.
A. Bar-Noy, Hebrew U.
D. Dolev, Hebrew U.
D. Koller, Hebrew U.
D. Peleg, Stanford U.
R. Reischuk, Technische Hochschule Darmstadt
10:40 Local management of a global resource in a communication network
Y. Afek, A.T.&T. Bell Labs
B. Awerbuch, M.I.T.
S. Plotkin, M.I.T.
M. Saks, Rutgers U. and Bell Communications Research
11:00 Applying static network protocols to dynamic networks
Y. Afek, A.T.&T. Bell Labs
B. Awerbuch, M.I.T.
E. Gafni, U.C.L.A.
11:20 Bounded time-stamps
A. Israeli, Harvard U.
M. Li, Harvard U.
11:40 Concurrent reading while writing II: the multi-writer case
G. Peterson, Georgia Tech.
J. Burns, Georgia Tech.
12:00 Lunch
Session 11. Chair: Joseph Halpern
2:00 Lower bounds to randomized algorithms for graph properties
A. Yao, Princeton U.
2:20 Exponential lower bounds for finding Brouwer fixed points
M. Hirsch, U.C. Berkeley
S. Vavasis, Stanford U.
2:40 Database theory and cylindric lattices
S. Cosmadakis, I.B.M. Watson Research Center
3:00 Secret linear congruential generators are not cryptographically
secure
J. Stern, U. Paris
3:20 A practical scheme for verifiable secret sharing
P. Feldman, M.I.T.
3:40 Break
Session 12. Chair: Shafi Goldwasser
4:10 Perfect zero-knowledge languages can be recognized in two rounds
W. Aiello, M.I.T.
J. Hastad, M.I.T.
4:30 Interactive proof systems: provers that never fail and random
selection
O. Goldreich, Technion
Y. Mansour, I.B.M. Haifa Scientific Center
4:50 On the cunning power of cheating verifiers: some observations
about zero knowledge proofs
Y. Oren, Technion
5:10 Random self-reducibility and zero knowledge interactive proofs
of possession of information
M. Tompa, I.B.M. Watson Research Center
H. Woll, U. Washington
5:30 End
∂18-Sep-87 1108 GANGOLLI@Sushi.Stanford.EDU Lectures on Sieves
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 18 Sep 87 11:08:15 PDT
Date: Fri 18 Sep 87 11:02:21-PDT
From: Anil R. Gangolli <GANGOLLI@Sushi.Stanford.EDU>
Subject: Lectures on Sieves
To: aflb.all@Sushi.Stanford.EDU
Office Phone: (415) 723-3605
Message-ID: <12335645099.27.GANGOLLI@Sushi.Stanford.EDU>
Prof. Selberg is giving two lectures on sieve methods this coming week
in the Mathematics Dept. Details follow:
SIEVE METHODS AND THEIR LIMITATIONS
Prof. A. Selberg
TIMES: 4:00pm Monday, Sept. 21
4:00pm Wednesday, Sept. 23
LOCATION: Stanford Mathematics Department
Bldg. 380 Room 380-W (in basement)
Tea is served before each lecture at 3:30pm in the third
floor lounge of the Math building.
Prof. Selberg plans to give a more detailed series of lectures
on sieves in October. Dates and times have not yet been announced.
--anil.
-------
∂18-Sep-87 1222 TAJNAI@score.stanford.edu Need Quotes for the Brochure
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 18 Sep 87 12:22:16 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Fri, 18 Sep 87 12:16:35 PDT
Date: Fri 18 Sep 87 12:14:29-PDT
From: Carolyn Tajnai <TAJNAI@score.stanford.edu>
Subject: Need Quotes for the Brochure
To: faculty@score.stanford.edu
Cc: hiller@score.stanford.edu
Message-Id: <12335658231.20.TAJNAI@Score.Stanford.EDU>
The designer, Mell Hall, has asked for quotes from us to use
in the new CSD Brochure.
So please, send me succinct, quotable quotes.
Thanks,
Carolyn
-------
∂18-Sep-87 1224 CBARSALOU@Score.Stanford.EDU Lawvere's visit: Talks next week
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 18 Sep 87 12:24:05 PDT
Date: Fri 18 Sep 87 12:19:03-PDT
From: Caroline Barsalou <CBARSALOU@Score.Stanford.EDU>
Subject: Lawvere's visit: Talks next week
To: conmod@Navajo.Stanford.EDU, aflb.su@Sushi.Stanford.EDU,
colloq@Score.Stanford.EDU, logic@CSLI.Stanford.EDU,
logmtc@Sail.Stanford.EDU
Message-ID: <12335659062.37.CBARSALOU@Score.Stanford.EDU>
Subject: Lawvere visit
Bill Lawvere will visit Stanford during Sept 23-28. He will present
recent work of his own, and will interact with some of us involved
in applications of category theory to computer science problems.
Over the past seventeen years Lawvere has had a considerable influence
on the direction taken by category theory research. Among his better
known contributions are topos theory, algebraic theories, and
hyperdoctrines.
Lawvere will give two talks, at the following times and places:
QUALITATIVE DISTINCTIONS BETWEEN TOPOSES OF GRAPHS
Sept. 23 1-2:30pm Bldg 420 Rm 050
Reflexive graphs form a topos of motion parametrizers, whereas the
topos of irreflexive graphs corresponds to a single object in the
former topos. Relations with Schutzenberger monoids are also
discussed.
RECENT RESULTS ON METRIC SPACES AS ENRICHED CATEGORIES.
Sept. 25 1-2:30pm Bldg 420 Rm 050
Categories support a rich family of relations and operations borrowed
from one or another particular category and generalized to all
categories. In this work we generalize certain metric space notions
including radius and geodesic distance.
It is hoped that the interactions may lead to a third talk illuminating
some of the issues in the applications we are interested in.
-------
∂18-Sep-87 1241 @Sushi.Stanford.EDU:CBARSALOU@Score.Stanford.EDU Lawvere's visit: Talks next week
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 18 Sep 87 12:41:16 PDT
Received: from Score.Stanford.EDU by Sushi.Stanford.EDU with TCP; Fri 18 Sep 87 12:19:32-PDT
Date: Fri 18 Sep 87 12:19:03-PDT
From: Caroline Barsalou <CBARSALOU@Score.Stanford.EDU>
Subject: Lawvere's visit: Talks next week
To: conmod@Navajo.Stanford.EDU, aflb.su@Sushi.Stanford.EDU,
colloq@Score.Stanford.EDU, logic@CSLI.Stanford.EDU,
logmtc@Sail.Stanford.EDU
Message-ID: <12335659062.37.CBARSALOU@Score.Stanford.EDU>
Subject: Lawvere visit
Bill Lawvere will visit Stanford during Sept 23-28. He will present
recent work of his own, and will interact with some of us involved
in applications of category theory to computer science problems.
Over the past seventeen years Lawvere has had a considerable influence
on the direction taken by category theory research. Among his better
known contributions are topos theory, algebraic theories, and
hyperdoctrines.
Lawvere will give two talks, at the following times and places:
QUALITATIVE DISTINCTIONS BETWEEN TOPOSES OF GRAPHS
Sept. 23 1-2:30pm Bldg 420 Rm 050
Reflexive graphs form a topos of motion parametrizers, whereas the
topos of irreflexive graphs corresponds to a single object in the
former topos. Relations with Schutzenberger monoids are also
discussed.
RECENT RESULTS ON METRIC SPACES AS ENRICHED CATEGORIES.
Sept. 25 1-2:30pm Bldg 420 Rm 050
Categories support a rich family of relations and operations borrowed
from one or another particular category and generalized to all
categories. In this work we generalize certain metric space notions
including radius and geodesic distance.
It is hoped that the interactions may lead to a third talk illuminating
some of the issues in the applications we are interested in.
-------
∂18-Sep-87 1402 @Sushi.Stanford.EDU:PHY@SAIL.STANFORD.EDU
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 18 Sep 87 14:02:50 PDT
Received: from SAIL.STANFORD.EDU by Sushi.Stanford.EDU with TCP; Fri 18 Sep 87 13:58:30-PDT
Date: 18 Sep 87 1400 PDT
From: Phyllis Winkler <PHY@SAIL.STANFORD.EDU>
To: aflb.su@SUSHI.STANFORD.EDU
TALK
The Complexity of Addition
by Nick Pippenger
Cost and delay of logical network for binary addition.
Classical results on bounded fan-in and recent results
for unbounded fan-in.
MONDAY September 21, 1987 9:30 a.m.
AMDAHL - Building 11
101 South to San Tomas - left 1 block to Scott.
Right on Scott to parking.
∂20-Sep-87 2049 BARWISE@CSLI.Stanford.EDU Mail problems
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Sep 87 20:49:14 PDT
Date: Sun 20 Sep 87 20:49:07-PDT
From: Jon Barwise <BARWISE@CSLI.Stanford.EDU>
Subject: Mail problems
To: ssp-faculty@CSLI.Stanford.EDU
Message-ID: <12336276204.12.BARWISE@CSLI.Stanford.EDU>
I just discoverd that the ssp-faculty mailing list has had some
problems. It was basically not well-formed. I don't know if this
means that some of you have not been getting your mail. Let me know
if you have not gotten mail about (1) the fall faculty lunch, and (2)
a new micro-computer programming course. Thanks, Jon
-------
∂20-Sep-87 2209 LANSKY@WARBUCKS.AI.SRI.COM REMINDER -- MONDAY PLANLUNCh
Received: from WARBUCKS.AI.SRI.COM by SAIL.STANFORD.EDU with TCP; 20 Sep 87 22:08:52 PDT
Date: Sun 20 Sep 87 22:01:21-PDT
From: Amy Lansky <LANSKY@WARBUCKS.AI.SRI.COM>
Subject: REMINDER -- MONDAY PLANLUNCh
To: planlunch_reminder
Message-ID: <559198881.0.LANSKY@WARBUCKS.AI.SRI.COM>
Mail-System-Version: <VAX-MM(215)+TOPSLIB(126)+PONY(165)@WARBUCKS.AI.SRI.COM>
REMINDER:
PLANLUNCH -- 11am, EJ228, September 21
Speaker: Sanjay Mittal, Xerox PARC
Visitors, please arrive at the E-building lobby 5 minutes before the talk.
-------
∂21-Sep-87 0125 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #61
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 Sep 87 01:25:07 PDT
Date: Sun 20 Sep 1987 19:21-PDT
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #61
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Monday, 21 Sep 1987 Volume 5 : Issue 61
Today's Topics:
Query - C & Goal Stacking,
Implementation - Mu & Nu & Quintus,
LP Library - Libraries
----------------------------------------------------------------------
Date: 16 Sep 87 02:05:55 GMT
From: duke!gleicher@mcnc.org (Michael Gleicher)
Subject: C & Goal Stacking
Can anyone provide me with any references about either of the
following:
1. Programs that compile Prolog into C or some other high level procedural
langauge
2. Goal Stacking architectures. (Warren mentions them briefly in the
"Abstract Prolog Machine" paper)
Please reply to the Digest.
Thank you.
-- Michael Lee Gleicher
------------------------------
Date: 16 Sep 87 03:45:17 GMT
From: Lee Naish <uunet!munnari!mulga!lee@seismo.css.gov>
Subject: MU-Prolog
MU-Prolog is still being distributed by I recommend its successor,
NU-Prolog, which is a compiler based system and has many more
features.
For most research I would recommend a compiler system. For teaching
the descision is not so clear cut. If you have lots of students in
relation to machine cycles/memory and the projects you are setting are
small then an interpreter is probably desirable.
To choose between different compiler/interpreter systems you should
compare features and cost. The thrust of our work at Melbourne Uni on
MU/NU-Prolog has been making the language closer to the ideals of
logic programming and having a good database facility.
-- Lee Naish
------------------------------
Date: 16 Sep 87 15:16:50 GMT
From: Sundar Iyengar <oliveb!intelca!mipos3!sundar@ames.arpa>
Subject: MU-Prolog
I have used both CProlog and Quintus extensively on the Apollo Domain
systems. I find that CProlog is adequate for routine Prolog
programming. Since the source code is available, you have a way to
implement unusual features by adding extra code.
Quintus has two advantages (it may have others, but I find these most
useful): a compilation facility and a foreign function interface.
Once your programs are stable, the run time can be increased by merely
compiling them. The foreign function interface comes in handy when
you have to use other languages for various reasons (example:
building a graphical editor using a graphics library on your machine
in C). Quintus also comes with an extensive on line help facility
which I found helpful once in a while.
-- Sundar
------------------------------
Date: Sun, 13 Sep 87 22:38:09 PDT
From: Edouard Lagache <lagache@violet.Berkeley.EDU>
Subject: Supplemental Predicate Library
I am sending a series or programs called "The PROLOG Supplemental
Predicate Libraries". People may freely distribute the libraries if
they distribute the package in its complete and unmodified form
including copyright and author credits. I am afraid that asking
people to pick up 10 files might be esentially hopeless, but it would
be better on all concerned if the libraries would be kept as a unit
(particularly for bug fixes).
The names of the files you will be receiving are:
ANSI_IO.PRO
ENV_FUNT.PRO
LD_LIB
LIST_SYM.PRO
PRO_LIB.DOC
READ.ME
STDDEF.PRO
STDIO.PRO
STDLIST.PRO
WINDOW.PRO
Let me know if there are any problems with dispensing this
package, and of course if you have any questions or comments
concerning the predicates themselves.
Thank you very much for your help!
-- Edouard Lagache
School of Education
U.C. Berkeley
lagache@violet.berkeley.edu
-------------------------------------------------------------------------------
Abstract: This is a set of libraries of Prolog predicates that
can be useful in a wide range of applications. This set includes
the following libraries: ANSI standard terminal manipulation,
Prolog environment functions, arithmetic and matching functions,
generic input/output functions, list manipulation functions, and
window device support.
Source code is in "Core" Prolog with occasional alternative solutions
for Automata Design Associates VML Prolog. Some code is specific to
microcomputers or VML PROLOG, but the bulk of the 50 Kilobytes of code
is general purpose. 46 pages of documentation is also provided.
[ These files will be posted one per issue for the next ten issues.
My apologies to those who are bothered by this redistribution
scheme. -ed ]
------------------------------
End of PROLOG Digest
********************
∂21-Sep-87 1917 NILSSON@score.stanford.edu Tues lunches
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 Sep 87 19:17:34 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Mon, 21 Sep 87 19:12:31 PDT
Date: Mon 21 Sep 87 19:16:13-PDT
From: Nils Nilsson <NILSSON@score.stanford.edu>
Subject: Tues lunches
To: faculty@score.stanford.edu
Message-Id: <12336521437.9.NILSSON@Score.Stanford.EDU>
We'll begin the Autumn Quarter of Faculty lunches on Tuesday, Sept. 29
at 12:15 p. m. To start the new policy of occasionally having these
lunches at some of our far-flung CS sites (and since mjh 146 in unavailable
on 9/29), our first lunch will be in the CIS conference room. Sandwiches
and softdrinks will be provided. At that lunch we will be welcoming
especially our new faculty members Andrew Goldberg and David Dill. I
would also like to sample faculty reaction about plans for libraries as
we move into the NWC.
Pse let me know if you think we ought to have more lunches with
topics and speakers (technical or non-technical) or more lunches with
nothing scheduled---to provide opportunities for faculty members to
chat informally with colleagues.
If more topic lunches are desired, pse send topic suggestions.
-Nils
-------
∂21-Sep-87 2311 @Sushi.Stanford.EDU:steve%hubcap.clemson.edu@forsythe.stanford.edu Minimal number of states for finite state machine
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 Sep 87 23:11:48 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Mon 21 Sep 87 23:08:10-PDT
Received: by lindy.stanford.edu; Mon, 21 Sep 87 22:21:31 PDT
Resent-From: steve%hubcap.clemson.edu@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Mon, 21 Sep 87 22:18:49 PDT
Date: 21 Sep 87 14:25:46 GMT
From: steve%hubcap.clemson.edu@forsythe.stanford.edu ("Steve" Stevenson)
Subject: Minimal number of states for finite state machine
Message-Id: <C102.THEORYNT@ibm.com>
Resent-Date: 22 Sep 1987 01:13:02-EDT (Tuesday)
Resent-Sender: THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Resent-To: aflb.tn@sushi.stanford.edu
Apparently-To: aflb.tn@sushi.stanford.edu
Is there an efficient algorithm for converting a finite state machine into
an equivalent machine with a minimal number of states? You may choose the
objective function.
This problem is being posed by Steve Hedetniemi, not on the net. I'll field
the answers.
--
Steve (really "D. E.") Stevenson steve@hubcap.clemson.edu
Department of Computer Science, (803)656-5880.mabell
Clemson University, Clemson, SC 29634-1906
∂22-Sep-87 0133 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #62
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 22 Sep 87 01:33:20 PDT
Date: Mon 21 Sep 1987 13:17-PDT
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #62
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Tuesday, 22 Sep 1987 Volume 5 : Issue 62
Today's Topics:
Implementation - MU Note,
LP Library - ansi_io.pro & env_funt.pro
----------------------------------------------------------------------
Date: 19 Sep 87 04:09:51 GMT
From: Lee Naish <munnari!mulga!lee@uunet.uu.net>
Subject: MU
MU-Prolog and (some versions of) CProlog also have foreign function
interfaces (though not quite as easy to use).
-- Lee Naish
------------------------------
Date: Sun, 13 Sep 87 22:38:46 PDT
From: Edouard Lagache <lagache@violet.Berkeley.EDU>
Subject: PROLOG library file: ansi_io.pro
/* File: ANSI_IO.PRO */
/******************************************************************************/
/* */
/* ANSI standard terminal input/output predicate definition file */
/* */
/* This file contains predicates and data which provide commonly */
/* needed input/output capabilities for interactive programming. It also*/
/* contains predicates to control any terminal which supports the ANSI */
/* standard terminal type. For IBM PC's and compatibles these commands */
/* will work only if the systems is booted up the the ANSI.SYS device */
/* driver. */
/* */
/* E. Lagache, Version - 1.00, February - 1987 */
/* Copyright(C) 1987, ALL RIGHTS RESERVED */
/* */
/* */
/* NOTE: This file has been designed for use with ADA PROLOG. */
/* Also these predicates were developed for use with a Texas */
/* Instruments Professional computer. Some adjustment of the */
/* screen attributes may be necessary for other machines. */
/* */
/******************************************************************************/
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'center_stg' prints out a string centered */
/* on an 80 column terminal screen. */
/* */
/* E. Lagache, Vers. - 1.00, Nov - 86 */
/* * * * * * * * * * * * * * * * * * * * * * * */
center_stg(String):- comp_tabs(String,Tabs), tab(Tabs),prtstr(String), nl.
/*##> 'comp_tabs' computes the number of <##*/
/*##> spaced needed to center the string. <##*/
/*##> <##*/
/*##> Used by Predicate: 'center_stg' <##*/
comp_tabs(String,Tabs):- length(String,Length), X is 80-Length, evenp(X),
Tabs is X/2, !.
comp_tabs(String,Tabs):- length(String,Length), X is 79-Length, evenp(X),
Tabs is X/2, !.
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'clear_end' deletes all characters after */
/* the cursor to the end of the screen */
/* */
/* E. Lagache, Vers. - 1.00, Feb - 87 */
/* * * * * * * * * * * * * * * * * * * * * * * */
clear_end:- prtstr("$[J").
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'clear_line' deletes all characters after */
/* the cursor on a given line */
/* */
/* E. Lagache, Vers. - 1.00, Feb - 87 */
/* * * * * * * * * * * * * * * * * * * * * * * */
clear_line:- prtstr("$[K").
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'clear_screen' send the required escape */
/* sequence to the terminal. */
/* */
/* E. Lagache, Vers. - 1.00, Feb - 87 */
/* * * * * * * * * * * * * * * * * * * * * * * */
clear_screen:- prtstr("$[2J").
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'locate_cursor' moves the cursor to the */
/* desired location on the screen */
/* */
/* E. Lagache, Vers. - 1.00, Feb - 87 */
/* * * * * * * * * * * * * * * * * * * * * * * */
locate_cursor(Row, Column):- prtstr("$["),write(Row),write(';'),
write(Column),prtstr("H"),!.
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'prtstr' sends a string to the current */
/* output string by converting the string to */
/* a name and using the 'write' predicate. */
/* */
/* E. Lagache, Vers. - 1.00, Feb - 87 */
/* */
/* Note: 'prtstr' is builtin to ADA VML */
/* PROLOG. */
/* * * * * * * * * * * * * * * * * * * * * * * */
/* prtstr(String) :- name(Atom,String), write(Atom). */
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'push_up' sends the requested number of */
/* newlnes to the output stream. */
/* */
/* E. Lagache, Vers. - 1.00, Dec - 86 */
/* * * * * * * * * * * * * * * * * * * * * * * */
push_up(0):- !.
push_up(I):- J is I-1, nl, push_up(J).
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'set_attribute' sets the charactaristics */
/* of characters after command. Argument */
/* specifies attribute */
/* */
/* E. Lagache, Vers. - 1.00, Feb - 87 */
/* * * * * * * * * * * * * * * * * * * * * * * */
set_attribute(reset):- prtstr("$[1m"). /* Reset to default setup */
set_attribute(underline):-prtstr("$[4;m"). /* underline characters */
set_attribute(blink):-prtstr("$[5;m"). /* blinking characters */
set_attribute(reverse):-prtstr("$[7;m"). /* reverse video characters */
/* Set character color */
set_attribute(black):-prtstr("$[30m"). /* black characters */
set_attribute(red):-prtstr("$[31m"). /* red characters */
set_attribute(green):-prtstr("$[32m"). /* green characters */
set_attribute(yellow):-prtstr("$[33m"). /* yellow characters */
set_attribute(blue):-prtstr("$[34m"). /* blue characters */
set_attribute(magenta):-prtstr("$[35m"). /* magenta characters */
set_attribute(cyan):-prtstr("$[36m"). /* cyan characters */
set_attribute(white):-prtstr("$[37m"). /* white characters */
/* End file: ANSI_IO.PRO */
------------------------------
Date: Sun, 13 Sep 87 22:39:13 PDT
From: Edouard Lagache <lagache@violet.Berkeley.EDU>
Subject: PROLOG library file: env_funt.pro
/* File: 'env-funt.pro' */
/***************************************************************************/
/* */
/* PROLOG environment enrichment functions */
/* */
/* This function library contains a number of predicates and operators */
/*that make the process or developing PROLOG programs under VML PROLOG */
/* more pleasant and productive. */
/* */
/* */
/* */
/* E. Lagache, Version - 1.10, July - 1987 */
/* (C) Copyright 1987, Edouard Lagache, All Rights Reserved */
*/
/* Note: To use these predicates with your favorite editor, replace */
/* the 'edit' name in the functor and operator with the name of */
/* your editor. Use whatever convention you like on the predicate */
/* of edit and load a file. */
/* */
/***************************************************************************/
?- op(255, fx, edit). /* define operators to reduce typing */
?- op(255, fx, ledit).
?- op(255, fx, run). /* Define shortcut for executing a shell command */
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'edit' calls up the editor to edit a file */
/* */
/* E. Lagache, Vers. - 1.10, Jul - 87 */
/* */
/* Note: 'concat' is specific to ADA PROLOG */
/* * * * * * * * * * * * * * * * * * * * * * * */
edit(Filename) :- name(Filename,Filestg), append(Filestg,".pro",Filext),
append("edit ",Filext,Command),name(Form,Command),
exec(Form),!.
/* Solution using ADA specific predicates */
/*edit(Filename):- concat(Command,['Edit ',Filename,'.pro']),exec(Command).*/
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'dos' invokes the operating system shell */
/* */
/* E. Lagache, Vers. - 1.00, Feb - 87 */
/* * * * * * * * * * * * * * * * * * * * * * * */
dos :- exec(command).
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'ledit' calls up the editor to edit a file */
/* and then loads it into the system. */
/* */
/* E. Lagache, Vers. - 1.10, Jul - 87 */
/* */
/* Note: 'concat' is specific to ADA PROLOG */
/* * * * * * * * * * * * * * * * * * * * * * * */
ledit(Filename) :- name(Filename,Filestg), append(Filestg,".pro",Filext),
append("edit ",Filext,Command),name(Form,Command),
exec(Form),forget(Filename),consult(Filename),!.
/* Solution using ADA specific predicates */
/* ledit(Filename) :- concat(Command,['Edit ',Filename,'.pro']), */
/* exec(Command),forget(Filename),consult(Filename). */
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'run' runs passes a command to the */
/* operating system for execution. */
/* */
/* E. Lagache, Vers. - 1.00, Feb - 87 */
/* * * * * * * * * * * * * * * * * * * * * * * */
run(Command) :- exec(Command).
/* End file: ENV_FUNT.PRO */
------------------------------
End of PROLOG Digest
********************
∂22-Sep-87 1152 TAJNAI@score.stanford.edu ANy work being done in....
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 22 Sep 87 11:52:01 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Tue, 22 Sep 87 11:47:57 PDT
Date: Tue 22 Sep 87 11:51:35-PDT
From: Carolyn Tajnai <TAJNAI@score.stanford.edu>
Subject: ANy work being done in....
To: faculty@score.stanford.edu
Message-Id: <12336702638.35.TAJNAI@Score.Stanford.EDU>
Translator or transformer that will accept sequential code for
a sequential processor and produce parallel code for a parallel
processor preferably in C or Fortran.
If you know of anything, please send me a message.
Carolyn
-------
∂23-Sep-87 0127 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #63
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Sep 87 01:27:51 PDT
Date: Tue 22 Sep 1987 13:03-PDT
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #63
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Wednesday, 23 Sep 1987 Volume 5 : Issue 63
Today's Topics:
LP Library - ld_lib & list_sym.pro & read.me
----------------------------------------------------------------------
Date: Sun, 13 Sep 87 22:39:41 PDT
From: Edouard Lagache <lagache@violet.Berkeley.EDU>
Subject: ld_lib
/* FILE: LD_LIB */
/* * * * * * * * * * * * * * * * * * * * * * * * */
/* */
/* Supplementary Predicate Libraries Loader File */
/* */
/* This file sets up the A.D.A. PROLOG */
/* Directory system to store all the predicates */
/* in the Supplementary Predicates Libraries in */
/* the directory 'system'. */
/* */
/* Edouard Lagache, Version - 1.1, July - 87 */
/* */
/* Note: This loader file works only with ADA */
/* PROLOG. Also it cannot be consulted */
/* like regular PROLOG source files. */
/* Instead it must be given as a */
/* line argument like this: */
/* */
/* PROLOG LD_LIB */
/* */
/* Finally, you may wish do adapt this */
/* loader file to include other files */
/* than the ones listed here. */
/* * * * * * * * * * * * * * * * * * * * * * * * */
/* Batch processing command mode */
batch.
/* Display an opening prompt to reassure user during process */
nlf(user). nlf(user).
prtstrf(user, " Installing Predicate Libraries").
nlf(user).
prtstrf(user, " 'ld_lib', E. Lagache, 7/87").
nlf(user). nlf(user).
chdom [root,system]. /* move to system directory */
/* Consult library files */
prtstrf(user, "consulting library 'ansi_io.pro'").
conscl('ansi_io'). nlf(user).
prtstrf(user, "consulting library 'env_funt.pro'").
conscl('env_funt'). nlf(user).
prtstrf(user, "consulting library 'stddef.pro'").
conscl('stddef'). nlf(user).
prtstrf(user, "consulting library 'stdlist.pro'").
conscl('stdlist'). nlf(user).
prtstrf(user, "consulting library 'window.pro'").
conscl('window.pro'). nlf(user).
/* Export symbols and return to 'user' directory */
nlf(user). prtstrf(user, "Setting directories").
export [ assoc, append, blink, black, blue, center_stg, comp_tabs,
clear_end, clear_line, clear_screen, cyan, call, countmatch,
current_count, collect_found, current_index_num, current_sum,
change_window, close_window, dos, delete, evenp, error,
end_window, findall, found, found_item, flatten, green, getnext,
gensym, get_next_num, get_head, get_index, get_tail, interval,
int_get_index, int_rev, locate_cursor, listp, last, list_sym,
magenta, max, min, make_assoc_list, merge, make_window, nthcdr,
nthelem, oddp, ptrstg, push_up, printall, quicksort, quisort1,
quisort2, reset, reverse, red, set_attribute, stringp, sum_match,
split1, split2, shift_l, shift_r, subst, sumlist, start_window,
store_symbols, underline, update_countmatch, update_sum_match,
white, yellow].
chdom [root,user].
import [ assoc, append, blink, black, blue, center_stg, comp_tabs,
clear_end, clear_line, clear_screen, cyan, call, countmatch,
current_count, collect_found, current_index_num, current_sum,
change_window, close_window, dos, delete, evenp, error,
end_window, findall, found, found_item, flatten, green, getnext,
gensym, get_next_num, get_head, get_index, get_tail, interval,
int_get_index, int_rev, locate_cursor, listp, last, list_sym,
magenta, max, min, make_assoc_list, merge, make_window, nthcdr,
nthelem, oddp, ptrstg, push_up, printall, quicksort, quisort1,
quisort2, reset, reverse, red, set_attribute, stringp, sum_match,
split1, split2, shift_l, shift_r, subst, sumlist, start_window,
store_symbols, underline, update_countmatch, update_sum_match,
white, yellow].
nlf(user). nlf(user).
nobatch.
see(user).
------------------------------
Date: Sun, 13 Sep 87 22:40:23 PDT
From: Edouard Lagache <lagache@violet.Berkeley.EDU>
Subject: list_sym.pro
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
/* */
/* A.D.A. VML PROLOG symbol listing utility */
/* */
/* 'store_symbols' stores the names of all symbols in the */
/* into a user specified file. This is useful for setting up lists */
/* of symbols to be exported from the A.D.A. symbol directory */
/* system, or in preparing documentation to support an appilcation. */
/* */
/* Edouard Lagache, Version - 1.10, July - 1987 */
/* */
/* Note: This predicate depends on A.D.A. specific predicates and */
/* will not function on other systems. */
/* */
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
/* 'store_symbols' sets up the file access for 'printall' */
store_symbols(File) :- open(File,w),printall(File),close(File).
/* 'printall' uses the 'object' predicate to list out all the names */
/* in the current directory. The technique used is */
/* similar in spirit to 'findall'. */
printall(File) :- object(X,symbol),printf(File,X),
prtstrf(File,", "),nlf(File), fail.
printall(_) :- !.
------------------------------
Date: Sun, 13 Sep 87 22:41:28 PDT
From: Edouard Lagache <lagache@violet.Berkeley.EDU>
Subject: READ.ME
September 4, 1987
PROLOG Supplemental Predicate Libraries
Edouard Lagache
Copyright (C) 1987, ALL RIGHTS RESERVED
Release - I, July - 1987
A B S T R A C T
This is a set of libraries of PROLOG predicates
that can be useful in a wide range of applications.
This set includes the following libraries: ANSI standard
terminal manipulation, PROLOG environment functions,
arithmetic and matching functions, generic input/output
functions, list manipulation functions, and window
device support.
SPECIAL NOTES AND ERRATA:
An early release to Automata Design Associates contained
two minor bugs: the call to 'prtstr' in the
'center_stg' predicate was misspelled, and an a number
of extraneous symbols were exported in the 'LD_LIB'
loader file. Both bugs have been fixed and the
documentation, and source code are believed to be
correct.
However, users should be warned that A.D.A. PROLOG
may suffer from interference from memory resident
programs. Such interference has caused A.D.A. VML
PROLOG to lock up while attempting to load up a
file, after having loaded up this library with
'LD_LIB'. Not using the directory scheme does not
always cure the problem. Users having this sort of
problem are advised to first try removing memory
resident programs before attempting other fixes.
NOTES ON PRINTING THE DOCUMENTATION:
The documentation should print on any standard line
printer. Continuous feed paper is recommended. The
documentation is approximately 46 pages.
------------------------------
End of PROLOG Digest
********************
∂23-Sep-87 0849 BARWISE@CSLI.Stanford.EDU Missing mail
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Sep 87 08:49:44 PDT
Date: Wed 23 Sep 87 08:48:41-PDT
From: Jon Barwise <BARWISE@CSLI.Stanford.EDU>
Subject: Missing mail
To: SSP-faculty@CSLI.Stanford.EDU
Message-ID: <12336931487.23.BARWISE@CSLI.Stanford.EDU>
It does seem that some of you have been missing some mail. Here are
two announcements for your calendar. In a seperate message, I will
send a description of the new course. Consulting faculty should
especially read it, since it provides a way for you to work with
students on progjects that interest you.
Faculty lunch, Monday, Oct 12, at the faculty club. Agenda will
follow.
Student--faculty lunch on the terrace, Thursday, Oct 15, in back of
building 60 (near the church) Lunch will be provided.
-------
∂23-Sep-87 0856 BARWISE@CSLI.Stanford.EDU New microcomputer program course
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Sep 87 08:56:39 PDT
Date: Wed 23 Sep 87 08:50:29-PDT
From: Jon Barwise <BARWISE@CSLI.Stanford.EDU>
Subject: New microcomputer program course
To: SSP-faculty@CSLI.Stanford.EDU
Message-ID: <12336931814.23.BARWISE@CSLI.Stanford.EDU>
To: SSP STudents and Faculty:
From: Jon Barwise
Re: New SSP Course: SSP 195
SSP 195 -- Microcomputer Programming Project
3-5 units per quarter, for at most nine units
Instructor: Any SSP faculty member
Course Description: Students develop software illustrating concepts
from symbolic systems using facilities at the SyD Student Development
Laboratory. Ideas for programming projects will be generated by
faculty or by students in consultation with SSP faculty. Particularly
appropriate are projects that produce software useful in SSP courses.
Projects will take place under faculty direction.
Prerequisites:
CS106X (or equivalent)
Familiarity with Macintosh, IBM PC, or other microcomputer, highly
desirable (e.g.by completing CS193)
Consent of an SSP faculty advisor. In many cases, this will be someone
from whom the student has taken and SSP course, and the project idea
will grow out of this course.
Approval of basic proposal for software by course instructor, with
the advice of SyD staff. Approval depends on feasibility of the
project, and its educational benefit to the student.
Sign up for SSP 195-xx, where xx is the number assigned to your
faculty advisor. (See SSP office for listing.)
---------------------------------------------------------------------
The course would operate along these lines:
-Prior to the course, other SSP courses would lead to contact between
interested students and faculty with ideas for programming projects.
-Faculty and students could also come to the program coordinator with
project ideas. The coordinator would act to match students and faculty
in undertaking projects. (This would provide an excellent opportunity
for students to work with the consulting faculty.)
-Once the project is approved, the student and faculty advisor would
meet with SyD staff to discuss project idea, assess feasibility,
etc.
-Then the student and faculty advisor would set up a preliminary
schedule for project and develop evaluation criteria.
-The units for the course would be determined by the faculty advisor
and course instructor based on the complexity of the project.
-It would be up to the student's advisor and the program direcotr to decide
if this course was appropriate for use in a particular concentration.
This would depend on both the nature of the project and the area of
concentration.
-Under special circumstances, such a project could be co-ordinated
with an honors project.
-One interesting possibility would be for students to spend the summer
on such a project.
-Before begining the project the faculty member and student should
agree as to who will own the program being produced. The basic
guidelines are that if it is the student's idea, then he will own the
program that he produces. However, if the student is developing a
faculty idea, then they should agree in advance as to who owns how
much of the program to be produces. This can be changed, but only by
mutual consent.
-------
∂23-Sep-87 1000 OKUNO@SUMEX-AIM.STANFORD.EDU [linton@lurch.stanford.edu (Mark Linton): next Bay Area Systems Seminar]
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Sep 87 10:00:05 PDT
Date: Wed, 23 Sep 87 09:56:59 PDT
From: Hiroshi "Gitchang" Okuno <Okuno@SUMEX-AIM.STANFORD.EDU>
Subject: [linton@lurch.stanford.edu (Mark Linton): next Bay Area Systems Seminar]
To: aap@SUMEX-AIM.STANFORD.EDU
Organization: Knowledge Systems Laboratory, CSD, Stanford University
Group: Heuristic Programming Project
Project: Advanced Architectures Project
Address: 701 Welch Road, Building C, Palo Alto, CA 94304-1703
Phone: +1 (415)725-4854
Message-ID: <12336943920.55.OKUNO@SUMEX-AIM.STANFORD.EDU>
Russ will give a talk on AIRTRAC at PARC.
- Gitchang -
---------------
Return-Path: <@Score.Stanford.EDU:linton@lurch.stanford.edu>
Received: from Score.Stanford.EDU by SUMEX-AIM.STANFORD.EDU with TCP; Mon, 21 Sep 87 14:56:00 PDT
Received: from lurch.stanford.edu ([36.22.0.14].#Internet) by SCORE.STANFORD.EDU with TCP; Mon 21 Sep 87 14:39:59-PDT
Received: by lurch.stanford.edu (1.2/Ultrix2.0-B)
id AA02324; Mon, 21 Sep 87 14:41:09 pdt
Date: Mon, 21 Sep 87 14:41:09 pdt
From: linton@lurch.stanford.edu (Mark Linton)
Message-Id: <8709212141.AA02324@lurch.stanford.edu>
To: su-events@lurch.stanford.edu
Subject: next Bay Area Systems Seminar
The next Bay Area Systems Seminar (BASS) will be held at Xerox PARC
on Friday October 2nd. All members of the Stanford community are welcome
to attend. If you do plan to attend, please send me a message by Monday
so that I can give Xerox a head count estimate.
Mark
The Tenth Bay Area Systems Seminar
Date: October 2, 1987
Location: Xerox Palo Alto Research Center (PARC)
3333 Coyote Hill Road
Palo Alto, California
How to find PARC from I-280:
Take the Page Mill Road off ramp, and go East towards Palo Alto.
Make a right turn at Coyote Hill Road
(first turn after stop light at Deer Creek road)
Xerox is on the left, just past the crest of the hill.
Go to the Auditorium door.
How to find PARC from US 101:
Take the Oregon Expressway off ramp, and go West towards Palo Alto.
The Oregon Expressway turns into Page Mill Road at El Camino Real.
Turn left on Foothill Expressway (it's about the tenth traffic light)
At the first traffic light, take a right onto Hillview Ave.
Xerox is the second driveway on the right.
Go to the Auditorium door.
Program: (talks are in the Auditorium)
9:30 Coffee (auditorium lobby)
10:00 Robert Garner (SUN),
The Scalable Processor Architecture (SPARC)
11:00 Mike Burrows (DEC SRC),
A Logic of Authentication
12:00 Lunch (patio)
1:00 Barbara B. Simons (IBM ARC)
Scheduling Sequential Loops on Parallel Processors
2:00 coffee
2:15 David Goldberg (SUN)
Comparing files on a Bitmap display
3:15 Russell Nakano (Stanford and DEC WSE)
Experiments with a Knowledge-Based System
on a Multiprocessor
Abstracts:
---------------------------------------------------------------------------
Robert Garner
SUN
The Scalable Processor Architecture (SPARC)
Abstract: The Scalable Processor Architecture (SPARC) was defined at
Sun Microsystems during the later part of 1984 by a team of
software and hardware designers. It is a refinement
of Berkeley's RISC II instruction set but also includes a
floating-point architecture and some extensions for tagged arithmetic.
It has been implemented with two Fujitsu 20K CMOS gate arrays and
two Weitek floating-point chips. Future designs are proceeding
in custom CMOS and ECL technologies. This talk will summarize
the architecture, with an emphasis on the "new" features,
and the tradeoffs that were involved in its defintion.
We will also discuss the gate array implementation and the
first SPARC system, the Sun-4/200, and its performance relative
to a similar system that uses a 68020 processor, the Sun-3/200.
---------------------------------------------------------------------------
Mike Burrows (speaker) and Roger Needham
DEC SRC
A Logic of Authentication
We have developed a logic which allows one to describe
authentication protocols and to prove their correctness.
It is useful for the designers and implementors of authentication
protocols because:
o it can determine the exact end state of the protocol
in terms of the beliefs of the two authenticated
parties.
o it shows up redundant information and redundant
encryption in the protocol.
o it highlights any undesirable assumptions that the
protocol relies upon in order to reach a desired end state.
o it uses concepts which can be understood (were
developed!) by people with little experience with
formal techniques.
We have built a theorem checker for the logic, and analysed various
published protocols, the results of which will be presented.
This work was done by Roger Needham and Mike Burrows at DEC SRC.
---------------------------------------------------------------------------
Barbara B. Simons (speaker) and Ash Munshi
IBM Almaden Research Center
Scheduling Sequential Loops on Parallel Processors
Automatic parallelization of code written in a sequential language
such as FORTRAN is of great importance for compilers for parallel
computers. We first discuss the problem of automatically
parallelizing iterative loops on multiprocessors and then derive a
scheduling problem that models a technique for the automatic
parallelization. We present polynomial time algorithms for some
special cases of this scheduling problem together with an upper bound
on a naive algorithm for the general case. Using one of the
polynomial time algorithms, we obtain a heuristic for the original
compiler problem. Finally, we present test results obtained by
applying our heuristic to EISPACK, a well known numerical analysis
FORTRAN package. In these tests the amount of parallelism we obtain
always equals and frequently surpasses that obtained by the best known
techniques in the literature.
This work is joint with Ash Munshi.
---------------------------------------------------------------------------
David Goldberg
SUN
Comparing files on a Bitmap display
One of the most useful tools in Unix is the 'diff' program. On bitmap
displays, it is common to run 'diff' in a terminal emulator window. Is
it possible to make use of the extra resolution to display the
differences in a more useful manner? A related problem is that of
merging two files. In the case when they were derived from a common
ancestor, there are four files involved: the ancestor, the two variants
and the merged result. What is the best way to present all this
information to the user?
'Filemerge' is one solution to these problems. I will describe how
'filemerge' works, and give the rationale for its design. I will also
report on our experiences in using 'filemerge' over the past six months.
---------------------------------------------------------------------------
Russell Nakano (speaker)
Stanford University, DEC Workstation Systems Engineering
and
Masafumi Minami
Stanford University, Sony
Experiments with a Knowledge-Based System on a Multiprocessor
This paper documents the results we obtained and the lessons we
learned in the design, implementation, and execution of a simulated
real-time application on a simulated parallel processor. Specifically,
we achieved linear speedup up to 100 times that obtainable on a single
processor.
The machine architecture is a distributed-memory multiprocessor.
We envision it running on a target machine consisting of 10 to 1000
processors, but because of simulator limitations, we ran simulations
of machines consisting of 1 to 100 processors. Each processor is
viewed as a full-scale multiprocessing machine. There is no global
shared memory; all processes communicate by message passing. The
target programming environment, called Lamina, encourages a programming
style that stresses performance gains through problem decomposition,
allowing many processors to be brought to bear on a problem. The key
is to distribute the processing load over replicated objects, and to
increase throughput by building pipelined sequences of objects that
handle stages of problem solving.
We focused on a knowledge-based application that simulates real-time
understanding of radar tracks, called Airtrac. This talk describes a
portion of the Airtrac application implemented in Lamina and a set of
experiments that we performed. We confirmed the following hypotheses:
1) Performance of our concurrent program improves with additional
processors, thereby attaining significant levels of speedup.
2) Correctness of our concurrent program can be maintained despite
a high degree of problem decomposition and highly overloaded input
data conditions.
-------
∂23-Sep-87 1643 TAJNAI@score.stanford.edu still need pithy quotes
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Sep 87 16:42:58 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Wed, 23 Sep 87 16:29:01 PDT
Date: Wed 23 Sep 87 16:38:25-PDT
From: Carolyn Tajnai <TAJNAI@score.stanford.edu>
Subject: still need pithy quotes
To: faculty@score.stanford.edu
Message-Id: <12337016999.10.TAJNAI@Score.Stanford.EDU>
Bruce Buchanan is the only one who sent quotes (for him and
EAF). Please send some more. Surely you can say something
profound about computer science that we can use.
Short, succinct, pithy, interesting, witty...
Carolyn
-------
∂24-Sep-87 0142 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #64
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Sep 87 01:42:28 PDT
Date: Wed 23 Sep 1987 10:41-PDT
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #64
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Thursday, 24 Sep 1987 Volume 5 : Issue 64
Today's Topics:
LP Library - stddef & stdio
----------------------------------------------------------------------
Date: Sun, 13 Sep 87 22:41:59 PDT
From: Edouard Lagache <lagache@violet.Berkeley.EDU>
Subject: stddef.pro
/* FILE: STDDEF.PRO */
/******************************************************************************/
/* */
/* Standard PROLOG Predicate and data definition file */
/* */
/* This file contains predicates and data which effectively extend */
/* the PROLOG environment. These extensions are in the area of */
/* arithmetic predicates, and predicates to convert matching into other */
/* useful forms such as lists, sums, or counts of frequency. */
/* */
/* E. Lagache, Version - 1.40, July - 1987 */
/* Copyright(C) 1986,1987, ALL RIGHTS RESERVED */
/* */
/******************************************************************************/
/* Adapt A.D.A. PROLOG to run C&M standard programs */
call(X) :- X.
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'concat' concatenates to atom names into */
/* a new atom. */
/* */
/* E. Lagache, Vers. - 1.00, Jul - 87 */
/* */
/* Note: A more powerful variant of this */
/* predicate is built-in to A.D.A. PROLOG */
/* * * * * * * * * * * * * * * * * * * * * * * */
concat(Name1,Name2,Result) :- name(Name1,Stg1),name(Name2,Stg2),
append(Stg1,Stg2,Stg3), name(Result,Stg3).
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'countmatch' returns the number of */
/* distinct matches of a variable X in a */
/* predicate 'Pred'. */
/* */
/* E. Lagache, Vers. - 1.10, Jul - 87 */
/* * * * * * * * * * * * * * * * * * * * * * * */
countmatch(Pred,_):- asserta(current_count(0)),
call(Pred), /* Satisfy Pred */
update_countmatch, /* and increment counter */
fail. /* fail to try to resatisfy */
/* Catch failure of above clause, and return count */
countmatch(_,Count):- current_count(Count), retract(current_count(Count)),!.
/* Increment counter */
update_countmatch:- current_count(I), J is I+1, retract(current_count(I)),
asserta(current_count(J)), !.
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'evenp' is true for even numbers. */
/* */
/* E. Lagache, Vers. - 1.00, Dec - 86 */
/* * * * * * * * * * * * * * * * * * * * * * * */
evenp(I):- integer(I), J is I mod 2, J == 0.
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'findall' returns a list of all the */
/* matches to the variable 'X' in the */
/* predicate 'Pred'. */
/* */
/* From Clocksin and Mellish p 162 */
/* */
/* E. Lagache, Vers. - 1.01, Dec - 86 */
/* * * * * * * * * * * * * * * * * * * * * * * */
findall(X,Pred,_):- asserta(found('Do not use this symbol!')),
call(Pred), /* Call predicate and store matches */
asserta(found(X)), fail. /* fail to force resatisfying */
/* This clause will be true when above has failed */
findall(_,_,Result):- collect_found([],Matchlist), !, /* Collect list */
Result = Matchlist. /* remove mark, and retract mark */
/* Collect matches in database and put on list */
collect_found(Partial,Matchlist) :- getnext(Item), !,
collect_found([Item|Partial],Matchlist).
collect_found(Matchlist,Matchlist).
/* Retrieve matches placed in database */
getnext(Item):- retract(found(Item)), !, Item \== 'Do not use this symbol!'.
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'gensym' is used to generate new constant */
/* symbols. This predicate takes a seed name */
/* and appends a number to differentiate */
/* between successive calls. */
/* */
/* E. Lagache, Vers. - 1.00, Mar - 87 */
/* */
/* Clocksin and Mellish pp 159-162 */
/* * * * * * * * * * * * * * * * * * * * * * * */
gensym(Root,Atom) :- get_next_num(Root,Num), /* get next number */
name(Root,Name1), /* make root a string */
integer_name(Num,Name2), /* make number a string */
append(Name1,Name2,Name), /* Concat strings */
name(Atom, Name). /* create symbol */
/* >>> predicate 'get_next_num' retrieves next number in the sequence <<< */
/* >>> Called from 'gensym' <<< */
get_next_num(Root,New) :- retract(current_index_num(Root,Num)), !,
New is Num + 1,
asserta(current_index_num(Root,New)).
get_next_num(Root,1) :- asserta(current_index_num(Root,1)).
/* >>> predicate 'integer_name' converts numbers to ASCII strings <<< */
/* >>> Called from 'gensym' <<< */
integer_name(Int,List) :- integer_name(Int,[],List).
integer_name(I,Sofar,[C|Sofar]) :- I < 10, !, C is I + 48.
integer_name(I, Sofar, List) :- Tophalf is I/10,
Bothalf is I mod 10,
C is Bothalf + 48,
integer_name(Tophalf,[C|Sofar],List).
/* Solution using ADA specific predicates */
/* NOTE: 'get_next_num' is needed from above */
/* gensym(Root,Atom) :- get_next_num(Root,Num), /* get a new number */
/* atoi(Symbol,Num), /* make a symbol out of it */
/* concat(Atom,[Root,Symbol]). /* concat symbols */
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'interval' generates all integers */
/* between 'Num1' and 'Num2'. */
/* */
/* E. Lagache, Vers. - 1.00, Nov - 86 */
/* * * * * * * * * * * * * * * * * * * * * * * */
interval(Num1,Num1,Num2). /* Select base of interval */
interval(Num0,Next,Num2):- Num0 < Num2, Num1 is Num0 + 1, /* Increment base */
interval(Num1,Next,Num2). /* of interval */
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'max' returns the largest of two numbers */
/* */
/* E. Lagache, Vers. - 1.00, Apr - 87 */
/* * * * * * * * * * * * * * * * * * * * * * * */
max(Number1,Number2,Number1) :- Number1 >= Number2, !.
max(Number1,Number2,Number2).
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'min' returns the smaller of two numbers */
/* */
/* E. Lagache, Vers. - 1.00, Apr - 87 */
/* * * * * * * * * * * * * * * * * * * * * * * */
min(Number1,Number2,Number1) :- Number1 =< Number2, !.
min(Number1,Number2,Number2).
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'oddp' is true for odd numbers. */
/* */
/* E. Lagache, Vers. - 1.00, Nov - 86 */
/* * * * * * * * * * * * * * * * * * * * * * * */
oddp(I):- integer(I), J is I mod 2, J \== 0.
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'stringp' tests to see if the item is a */
/* string. Since all strings are lists of */
/* ASCII codes, the predicate just tests if */
/* item is a list. */
/* */
/* E. Lagache, Vers. - 1.10, Jul - 87 */
/* * * * * * * * * * * * * * * * * * * * * * * */
stringp([]).
stringp([_|_]).
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'sum_match' returns the sum of an */
/* numerical field of predicate 'Pred'. */
/* The field name must be instantiated to */
/* 'X'. The result is returned in 'Sum'. */
/* */
/* E. Lagache, Vers. - 1.00, Nov - 86 */
/* * * * * * * * * * * * * * * * * * * * * * * */
/* Start by finding all values of 'X' and maintaining a running total in */
/* 'current_sum' */
sum_match(X,Pred,_):- assertz(current_sum(0)), /* Store 0 */
call(Pred), /* Try to satisfy */
update_sum_match(X), /* if possible store result */
fail. /* fail to try to resatisfy */
/* when first rule fails this rule will recover sum */
sum_match(_,_,Sum):- current_sum(Sum), retract(current_sum(Sum)), !.
/* This rule computes and stores running total in database */
update_sum_match(X):- integer(X),current_sum(I), J is I+X,
retract(current_sum(I)),assertz(current_sum(J)), !.
/* end file: STDDEF.PRO */
------------------------------
Date: Sun, 13 Sep 87 22:42:57 PDT
From: Edouard Lagache <lagache@violet.Berkeley.EDU>
Subject: stdio.pro
/* FILE: STDIO.PRO */
/******************************************************************************/
/* */
/* Standard PROLOG input/output predicate definition file */
/* */
/* This file contains predicates and data which provide commonly */
/* needed input/output capabilities for interactive programming. */
/* */
/* E. Lagache, Version - 1.03, July - 1987 */
/* Copyright(C) 1987, ALL RIGHTS RESERVED */
/* */
/* Note: These predicates assume nothing more intelligent than a */
/* generic dumb terminal. For more intelligent terminal */
/* use the predicate library contained in the file 'ANSI-IO.PRO' */
/* */
/******************************************************************************/
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'center_stg' prints out a string centered */
/* on an 80 column terminal screen. */
/* */
/* E. Lagache, Vers. - 1.00, Nov - 86 */
/* * * * * * * * * * * * * * * * * * * * * * * */
center_stg(String):- comp_tabs(String,Tabs), tab(Tabs),p_stg(String), nl.
/*##> 'comp_tabs' computes the number of <##*/
/*##> spaced needed to center the string. <##*/
/*##> <##*/
/*##> Used by Predicate: 'center_stg' <##*/
comp_tabs(String,Tabs):- length(String,Length), X is 80-Length, evenp(X),
Tabs is X/2, !.
comp_tabs(String,Tabs):- length(String,Length), X is 79-Length, evenp(X),
Tabs is X/2, !.
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'clear_screen' does a "poor mans" screen */
/* clearing by sending newlines. The */
/* directly send the required lines to */
/* increase speed. */
/* */
/* E. Lagache, Vers. - 1.00, Dec - 86 */
/* * * * * * * * * * * * * * * * * * * * * * * */
clear_screen:- nl,nl,nl,nl,nl,nl,nl,nl,nl,nl,nl,nl,nl,nl,nl,nl,nl,nl,nl,nl,
nl,nl,nl,nl,nl.
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'prtstr' provides efficient writing of */
/* strings by converting them to atom names */
/* and using 'write' */
/* */
/* Note: This predicate is builtin to ADA */
/* PROLOG. */
/* */
/* E. Lagache, Vers. - 1.01, Jul - 87 */
/* * * * * * * * * * * * * * * * * * * * * * * */
prtstr(String):- name(Atom,String), write(Atom).
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'push_up' sends the requested number of */
/* newlines to output. */
/* */
/* E. Lagache, Vers. - 1.00, Dec - 86 */
/* * * * * * * * * * * * * * * * * * * * * * * */
push_up(0):- !.
push_up(I):- J is I-1, nl,push_up(J).
/* End file: STDIO.PRO */
------------------------------
End of PROLOG Digest
********************
∂24-Sep-87 0312 @RELAY.CS.NET:yuasa%kurims.kurims.kyoto-u.junet@UTOKYO-RELAY.CSNET Japanese Activities toward Lisp Standardization
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 24 Sep 87 03:12:38 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa25268; 24 Sep 87 6:13 EDT
Received: from utokyo-relay by RELAY.CS.NET id ay09298; 24 Sep 87 6:00 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
id AA23717; Thu, 24 Sep 87 17:39:32 JST
Received: by titcca.cc.titech.junet (4.12/6.2Junet)
id AA00464; Thu, 24 Sep 87 17:14:20 jst
Received: by nttlab.NTT (4.12/6.2NTT.g) with TCP; Thu, 24 Sep 87 15:58:47 jst
Received: by kuis.kuis.kyoto-u.junet (2.0/6.2Junet)
id AA16011; Thu, 24 Sep 87 14:50:53 jst
Received: by kurims.kurims.kyoto-u.junet (3.2/6.2Junet)
id AA01964; Thu, 24 Sep 87 14:37:43 JST
Date: Thu, 24 Sep 87 14:37:43 JST
From: Taiichi Yuasa <yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <yuasa@kurims.kurims.kyoto-u.junet>
Message-Id: <8709240537.AA01964@kurims.kurims.kyoto-u.junet>
To: x3j13@SAIL.STANFORD.EDU
Subject: Japanese Activities toward Lisp Standardization
Japanese Activities toward Lisp Standardization
The demand for Lisp standardization has been growing rapidly in Japanese
computer industries and academic organizations. AIST (Agency of Industrial
Science and Technology), which is responsible for Japan Industrial Standards
(JIS in short), has initiated its activity toward JIS Lisp standardization.
In April 1986, in response to the request from AIST, a working group for Lisp
standardization was formed at JEIDA (Japan Electronic Industry Development
Association). After one year's preliminary discussions, the following
committee "JEIDA Committee for Lisp Standardization" was formed and its
active efforts have begun in June 1987. The aim of this committee is to
develop a Lisp language specification suitable for JIS standard in cooperation
with ISO and the organizations for Lisp standardization in other countries.
JEIDA Committee for Lisp Standardization
----------------------------------------
Chairman:
Takayasu Ito (Tohoku University)
Secretaries:
Tsuneo Furuyama (NTT: Nippon Telegraph and Telephone Corp.)
Fumio Motoyoshi (ETL: Electrotechnical Laboratory)
Taiichi Yuasa (Kyoto University)
Members from Major Computer Companies:
Fujitsu Ltd.
Hitachi Ltd.
IBM Japan Ltd.
Mitsubishi Electric Corp.
NEC Corp.
Oki Electric Industry Co. Ltd.
Toshiba Corp.
Observers:
Masayuki Ida (Aoyama Gakuin University)
Tetsuo Ida (The Institute of Physical and Chemical Research)
Ryo Kamito (AIST)
Masakazu Nakanishi (Keio University)
Takehisa Nireki (JEIDA)
Kentaro Shimizu (University of Tokyo)
Technical issues for Lisp standardization will be discussed by the subsidiary
working group "JEIDA Technical Working Group for Lisp Standardization", or
TG/A in short. This group started technical discussions soon after it was
formed in August 1987. It has been agreed that Common Lisp is a good starting
point for technical discussions. But various technical deficiencies of Common
Lisp have been already pointed out at TG/A. The role of TG/A is to clear up
major technical issues for Lisp standardization, continuing detailed technical
examinations on Common Lisp and other Lisp dialects.
JEIDA Technical Working Group for Lisp Standardization
------------------------------------------------------
Chairman:
Taiichi Yuasa (Research Institute for Mathematical Sciences,
Kyoto University)
Members:
Takashi Chikayama (ICOT)
Etsuya Shibayama (Dept. of Information Science,
Tokyo Institute of Technology)
Kentaro Shimizu (Dept. of Information Science, University of Tokyo)
Akikazu Takeuchi (Central Research Lab., Mitsubishi Electric Corp.)
Kyoji Umemura (NTT Software Lab., NTT)
Advisors:
Toshiaki Kurokawa (Tokyo Research Lab., IBM Japan Ltd.)
Michiaki Yasumura (Central Research Lab., Hitachi Ltd.)
Anyone interested in Japanese activities for Lisp standardization should
contact:
Professor Takayasu Ito
Department of Information Engineering
School of Engineering
Tohoku University
Sendai 980, Japan
Junet: chairlsp@nttlab.ntt.junet
or
Dr. Taiichi Yuasa
Research Institute for Mathematical Sciences
Kyoto University
Kyoto 606, Japan
Junet: yuasa@kurims.kurims.kyoto-u.junet
∂24-Sep-87 1204 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Seminars
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Sep 87 12:04:34 PDT
Date: Thu 24 Sep 87 12:02:42-PDT
From: Anil R. Gangolli <GANGOLLI@Sushi.Stanford.EDU>
Subject: Upcoming AFLB Seminars
To: aflb.all@Sushi.Stanford.EDU
Office Phone: (415) 723-3605
Message-ID: <12337228950.27.GANGOLLI@Sushi.Stanford.EDU>
Here are the abstracts for the first two AFLB seminars of the coming
quarter.
1-October-87: Andrew Goldberg (Stanford)
A Very Simple Algorithm for
the Minimum-Cost Circulation Problem
A classical algorithm for finding a minimum-cost circulation consists
of repeatedly finding a residual cycle of negative cost and canceling
it by pushing enough flow around the cycle to saturate an arc. We
show that a judicious choice of cycles for canceling leads to a
polynomial bound on the number of iterations in this algorithm. This
gives a very simple strongly polynomial algorithm that uses no
scaling. A variant of the algorithm that uses dynamic trees runs in
O(nm log n * min{log (nC),m log n}) time on a network of n
vertices, m arcs, and arc costs of maximum absolute value C. This
bound is comparable to those of the fastest previously known
algorithms.
Joint work with Robert Tarjan (Princeton and Bell Labs.).
***** Time and place: Thurs, October 1, 12:30pm in MJH 352 (Bldg. 460) *****
8-October-87: Marek Karpinski (Univ. of Bonn, IBM Almaden)
The Parallel Complexity
of Perfect Matching Problems
We construct fast parallel algorithms for deciding, constructing, and
enumerating all the perfect matchings in bipartite graphs with
polynomially bounded permanents. Some implications towards the
parallel complexity of general matching and counting problems are
formulated.
***** Time and place: Thurs, October 8, 12:30pm in MJH 352 (Bldg. 460) *****
-------
∂25-Sep-87 1029 ullman@navajo.stanford.edu paper received
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 25 Sep 87 10:29:41 PDT
Received: by navajo.stanford.edu; Fri, 25 Sep 87 10:19:05 PDT
Date: Fri, 25 Sep 87 10:19:05 PDT
From: Jeff Ullman <ullman@navajo.stanford.edu>
Subject: paper received
To: nail@navajo.stanford.edu
" Introduction to Logic Programming"
K. R. Apt, Dept. of CS, U Texas
A pretty lucid survey of LP and deductive databases.
---jeff
∂25-Sep-87 1106 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #65
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 25 Sep 87 11:06:19 PDT
Date: Thu 24 Sep 1987 10:19-PDT
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #65
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Friday, 25 Sep 1987 Volume 5 : Issue 65
Today's Topics:
LP Library - window & stdlist
----------------------------------------------------------------------
Date: Sun, 13 Sep 87 22:44:22 PDT
From: Edouard Lagache <lagache@violet.Berkeley.EDU>
Subject: window.pro
/* FILE: WINDOW.PRO */
/******************************************************************************/
/* */
/* TIPC window device input/output predicate definition file */
/* */
/* This file contains predicates to operate the 'WINDOW.SYS' device */
/* developed by Greg Haley of Texas Instruments. These predicates */
/* can (and probably should be used) with the 'ansi_io.pro' headers file */
/* since standard ANSI terminal codes can also be used to manipulate the */
/* windows. These predicates only handle the window manipulation that */
/* cannot be done with 'ansi_io.pro' */
/* */
/* E. Lagache, Version - 1.01, July - 1987 */
/* Copyright(C) 1987, ALL RIGHTS RESERVED */
/* */
/* */
/* NOTE: This file has been designed for use with A.D.A. PROLOG. */
/* */
/******************************************************************************/
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'change_window' changes the active window. */
/* the numerical argument is the number of */
/* the window in their order of creation. */
/* */
/* E. Lagache, Vers. - 1.00, Mar - 87 */
/* * * * * * * * * * * * * * * * * * * * * * * */
change_window(Number) :- prtstr("$[Wa"),write(Number),prtstr("w").
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'close_window' closes last opened window. */
/* */
/* E. Lagache, Vers. - 1.00, Mar - 87 */
/* */
/* Note: windows can only be closed in the */
/* reverse order of their creation. */
/* * * * * * * * * * * * * * * * * * * * * * * */
close_window:- prtstr("$[Wcw").
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'end_window' returns control to the 'CON:' */
/* device. Note that it is best to close all */
/* all windows before issuing this command. */
/* */
/* E. Lagache, Vers. - 1.00, Mar - 87 */
/* * * * * * * * * * * * * * * * * * * * * * * */
end_window :- prtstr("$[Wew").
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'make_window' creates a window of desired */
/* size. The parameters are: starting row */
/* and column, number of rows and columns in */
/* window. */
/* */
/* E. Lagache, Vers. - 1.00, Mar - 87 */
/* * * * * * * * * * * * * * * * * * * * * * * */
make_window(St_row,St_col,Row_tall,Col_width) :- prtstr("$[Wo"), write(St_row),
put(59),write(St_col),put(59),
write(Row_tall),put(59),
write(Col_width),prtstr("w").
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'start_window' sets the standard output */
/* device to be '_WINDOWS' instead of 'CON:' */
/* this command must be directed to the */
/* '_WINDOWS' device. */
/* */
/* E. Lagache, Vers. - 1.10, Jul - 87 */
/* * * * * * * * * * * * * * * * * * * * * * * */
start_window :- tell('_WINDOWS'), prtstr("$[Wbw"), tell(user).
/* End file: WINDOW.PRO */
------------------------------
Date: Sun, 13 Sep 87 22:43:54 PDT
From: Edouard Lagache <lagache@violet.Berkeley.EDU>
Subject: stdlist.pro
/* file: STDLIST.PRO */
/******************************************************************************/
/* */
/* PROLOG Standard Library of List Manipulation Predicates */
/* */
/* This library contains a collection of predicates commonly found */
/* in languages like LISP to facilitate the use of lists as a data */
/* structure. */
/* */
/* E. Lagache, Version - 1.10, July - 1987 */
/* Copyright(C) 1987, ALL RIGHTS RESERVED */
/* */
/******************************************************************************/
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'assoc' is true if there is sublist in */
/* first argument whose 'car' is equal to the */
/* second argument. This can be used to */
/* implement variable bindings. */
/* */
/* Inspired by similar function in Franz LISP */
/* */
/* E. Lagache, Vers. - 1.00, Feb - 87 */
/* */
/* Note 1: This predicate will find all such */
/* sublists */
/* Note 2: The 'make_assoc_list' predicate */
/* in this library is a convenient */
/* way to build these sort of lists. */
/* * * * * * * * * * * * * * * * * * * * * * * */
assoc(_,[],error):- !,fail. /* Base recursive case, No such element found */
assoc(Item,[Pair|_],Pair):- found_item(Pair,Item). /* Successful match */
assoc(Item,[_|Rest],Pair):- assoc(Item,Rest,Pair). /* Continue search */
found_item([Item|_],Item). /* test if 'car' of list is 'Item' */
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'append' combines two lists into a single */
/* list. */
/* */
/* From Clocksin and Mellish p 63 */
/* */
/* E. Lagache, Vers. - 1.00, Nov - 86 */
/* * * * * * * * * * * * * * * * * * * * * * * */
append([],List,List). /* Base recursive case */
/* Transfer elements from list1 to list3 */
append([Item|Tail1],List2,[Item|Tail3]):- append(Tail1,List2,Tail3).
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'delete' is a predicate with two forms: */
/* 1.) delete all occurrences of an item. */
/* 2.) delete first N occurrences of an */
/* item. */
/* */
/* form 1 takes arguments: */
/* delete(Item, List, Result). */
/* form 2 takes arguments: */
/* delete(Item, List, N, Result). */
/* */
/* Form 1 is from Clocksin and Mellish p 151 */
/* */
/* E. Lagache, Vers. - 1.00, Dec - 86 */
/* * * * * * * * * * * * * * * * * * * * * * * */
/*** FORM-1 ***/
delete(_,[],[]). /* Base case: no list to delete from */
/* found an occurrence, remove item */
delete(Item, [Item|List], Result):- !, delete(Item,List,Result).
/* 'Head' not item, so copy to 'Result' list */
delete(Item, [Head|List], [Head|Result]):- !, delete(Item,List,Result).
/*** FORM-2 ***/
/* Base case1: deleted correct number of times */
delete(Item,[Item|Result],1,Result):- !.
delete(_,[],_,[]):- !. /* Base case2: no list to delete from */
/* found an occurrence, remove item and decrement counter */
delete(Item, [Item|List], Number, Result):- !, Next is Number-1,
delete(Item,List,Next,Result).
/* 'Head' not item, so copy to 'Result' list */
delete(Item, [Head|List], N, [Head|Result]):- !, delete(Item,List,N,Result).
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'flatten' eliminates any sublists in the */
/* first argument, and returns a list with */
/* all elements in the top level. */
/* */
/* Solution to assignment 3.11 (Bratko). */
/* */
/* Note: this function is doubly recursive */
/* and uses the recursive 'append'; */
/* thus it is computationally expensive.*/
/* */
/* E. Lagache, Vers. - 1.01, Jul - 87 */
/* * * * * * * * * * * * * * * * * * * * * * * */
flatten([],[]):- !. /* Base case */
flatten([Head|T],X):- listp(Head),flatten(Head,Y), /* Element a list? flatten */
flatten(T,Z),append(Y,Z,X),!. /* Append list together */
flatten([Head|T],[Head|X]):- flatten(T,X),!. /* Else 'cdr' down list */
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'get_head' returns the first 'Number' of */
/* elements in 'List'. If the list is */
/* smaller than 'Number', then the whole list */
/* is returned. */
/* */
/* E. Lagache, Vers. - 1.00, Dec - 86 */
/* * * * * * * * * * * * * * * * * * * * * * * */
get_head(List,0,[]):- !. /* Reached end of index */
get_head([],_,[]):- !. /* Reached end of list */
/* Transfer current first element of list to list of heads */
get_head([Head|Tail],Index,[Head|Result]):- Next is Index-1,
get_head(Tail,Next,Result).
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'get_index' returns the places in the */
/* 'List' where 'Element' is located (i.e. */
/* 'get_index(b,[a,b,c],X) returns X=2). */
/* If 'Element' is not found predicate fails. */
/* */
/* E. Lagache, Vers. - 1.00, Dec - 86 */
/* * * * * * * * * * * * * * * * * * * * * * * */
/* Call internal function */
get_index(Element,List,Index):- int_get_index(Element,List,Index,1).
int_get_index(Element,[],_,_):- !,fail. /* if an empty list is found, fail */
int_get_index(Element,[Element|_],Result,Result). /* if found return */
/* Else "cdr" down list */
int_get_index(Element,[_|Tail],Result,Index):- Next is Index+1,
int_get_index(Element,Tail,Result,Next).
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'get_tail' returns the number of elements */
/* counting from the end of the list. If the */
/* list is smaller than the number, the whole */
/* list is returned. */
/* */
/* Note: 'get_tail' uses 'nthcdr' to access */
/* the desired elements. */
/* */
/* E. Lagache, Vers. - 1.00, Dec - 86 */
/* * * * * * * * * * * * * * * * * * * * * * * */
/* Return list if requested size is larger than list */
get_tail(List,Index,List):- length(List,Length), Length < Index, !.
get_tail(List,Index,Answer):- length(List,Length), Count is Length-Index,
nthcdr(List,Count,Answer).
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'nthcdr' returns the remainder of the list */
/* after removing the first 'N' elements. */
/* If there are less elements than 'N', the */
/* empty list is returned. */
/* */
/* Inspired by the analog function of Franz */
/* LISP. */
/* */
/* E. Lagache, Vers. - 1.00, Dec - 86 */
/* * * * * * * * * * * * * * * * * * * * * * * */
nthcdr(Tail,0,Tail). /* Finished index base case */
nthcdr([],_,[]):- !,fail. /* Empty list base case, fail*/
/* Remove elements */
nthcdr([_|Tail],Index,Result):- Next is Index-1, nthcdr(Tail,Next,Result).
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'last' returns the last element of the */
/* list. */
/* */
/* E. Lagache, Vers. - 1.00, Nov - 86 */
/* * * * * * * * * * * * * * * * * * * * * * * */
last([Element],Element):- !.
last([_|Rest],Element):- last(Rest,Element).
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'length' returns the number of elements */
/* in the top level of the list. */
/* */
/* E. Lagache, Vers. - 1.00, Nov - 86 */
/* */
/* Note: Length is already supplied by most */
/* PROLOGs (including A.D.A. PROLOG) */
/* * * * * * * * * * * * * * * * * * * * * * * */
/* length([],0). */
/* length([_|Tail], NewLength):- length(Tail,OldLength), */
/* NewLength is OldLength+1. */
/* * * * * * * * * * * * * * * * * * * * * * * */
/* Definition of a list 'listp'. */
/* */
/* E. Lagache, Vers. - 1.01, Dec - 86 */
/* * * * * * * * * * * * * * * * * * * * * * * */
listp([]).
listp([_|_]).
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'make_assoc_list' combines two lists with */
/* the same number of elements so that the */
/* elements of the two lists are paired by */
/* order. Predicate fails in lists are not */
/* of the same length. This predicate is */
/* identical to the 'merge' predicate except */
/* that it stores each pair in a sublist. */
/* */
/* */
/* E. Lagache, Vers. - 1.00, Jul - 87 */
/* * * * * * * * * * * * * * * * * * * * * * * */
make_assoc_list([],[],[]).
make_assoc_list([],List2,List2):- !, fail. /* Cases where list length is not */
make_assoc_list(List1,[],List1):- !, fail. /* equal - fail. */
/* Merge by taking heads from both lists and placing on merged list */
make_assoc_list([Head1|Tail1],[Head2|Tail2],[[Head1,Head2]|R]):-
make_assoc_list(Tail1,Tail2,R), !.
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'member' determines if 'Element' is a */
/* member of 'List'. */
/* */
/* From Clocksin and Mellish p 55 */
/* */
/* E. Lagache, Vers. - 1.00, Nov - 86 */
/* */
/* Note: 'member' is supplied by A.D.A. PROLOG */
/* * * * * * * * * * * * * * * * * * * * * * * */
/* member(Element,[Element|_]). */
/* member(Element,[_|Tail]):- member(Element,Tail). */
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'merge' combines two lists with the same */
/* same number of elements so that the */
/* elements of the two lists are paired by */
/* order. Predicate fails in lists are not */
/* of the same length. */
/* */
/* */
/* E. Lagache, Vers. - 1.00, Nov - 86 */
/* * * * * * * * * * * * * * * * * * * * * * * */
merge([],[],[]).
merge([],List2,List2):- !, fail. /* Cases where list length is not equal */
merge(List1,[],List1):- !, fail.
/* Merge by taking heads from both lists and placing on merged list */
merge([Head1|Tail1],[Head2|Tail2],[Head1,Head2|R]):- merge(Tail1,Tail2,R), !.
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'nthelem' returns the element in the */
/* 'Index' place of the list. */
/* */
/* E. Lagache, Vers. - 1.00, Dec - 86 */
/* * * * * * * * * * * * * * * * * * * * * * * */
nthelem([],_,error):- !, fail. /* fail if list is smaller than index */
nthelem([Item|_],1,Item):- !. /* return item */
nthelem([X|Rest],NewIndex,Item):- Index is NewIndex-1,nthelem(Rest,Index,Item).
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'quicksort' uses the quicksort algorithm */
/* to order a list of items. Two forms are */
/* provided: */
/* 1.) Sort based on numerical ranking. */
/* 2.) Sort based on some comparison */
/* predicate 'Pred'. */
/* */
/* Form 1 is from Clocksin and Mellish p 157 */
/* */
/* E. Lagache, Vers. - 1.00, Nov - 86 */
/* * * * * * * * * * * * * * * * * * * * * * * */
/*** FORM-1 ***/
/* Call internal function */
quicksort(Unsort,Result):- quisort1(Unsort,Result,[]).
/* Break problem up, and solve recursively */
quisort1([Item|Tail],Sort,Partial1):- split1(Item,Tail,Part1,Part2),
quisort1(Part2,Partial2,Partial1),
quisort1(Part1,Sort,[Item|Partial2]).
quisort1([],Sort,Result):- !,Sort=Result.
/* Partition list */
split1(Item,[Head|List],[Head|Small],Big):- Head =< Item,
split1(Item,List,Small,Big).
split1(Item,[Head|List],Small,[Head|Big]):- Head > Item,
split1(Item,List,Small,Big).
split1(_,[],[],[]).
/*** FORM-2 ***/
quicksort(Unsort,Pred,Result):- quisort2(Unsort,Pred,Result,[]).
/* Break problem up, and solve recursively */
quisort2([Item|Tail],Pred,Sort,Partial1):- split2(Item,Tail,Pred,Part1,Part2),
quisort2(Part2,Pred,Partial2,Partial1),
quisort2(Part1,Pred,Sort,[Item|Partial2]).
quisort2([],_,Sort,Result):- !,Sort=Result.
/* Partition list */
split2(Item,[Head|List],Pred,Small,[Head|Big]):- Test =.. [Pred,Head,Item],
call(Test),
split2(Item,List,Pred,Small,Big).
split2(Item,[Head|List],Pred,[Head|Small],Big):- Test =.. [Pred,Head,Item],
not(call(Test)),
split2(Item,List,Pred,Small,Big).
split2(_,[],_,[],[]).
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'reverse' reverses the order of elements */
/* in a list. */
/* */
/* From Clocksin and Mellish p 150 */
/* */
/* E. Lagache, Vers. - 1.01, Dec - 86 */
/* */
/* Note: 'List' must be instantiated for */
/* predicate to operate. */
/* * * * * * * * * * * * * * * * * * * * * * * */
reverse(List, Result):- int_rev(List,[],Result), !. /* Call to int. function */
/* move items one at a time */
int_rev([Item|Tail1],Partial,Result):- int_rev(Tail1,[Item|Partial],Result).
int_rev([],Result,Result).
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'shift_l' cyclically moves the list */
/* elements to the left by putting the head */
/* of the list at the tail. */
/* */
/* E. Lagache, Vers. - 1.00, Dec - 86 */
/* * * * * * * * * * * * * * * * * * * * * * * */
shift_l([Head|Tail],Result):- append(Tail,[Head],Result).
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'shift_r' cyclically moves the list */
/* to the right by putting the last element */
/* on the head of the list. */
/* */
/* E. Lagache, Vers. - 1.00, Dec - 86 */
/* * * * * * * * * * * * * * * * * * * * * * * */
shift_r(List,[End|Tail]):- last(List,End),delete(End,List,Tail).
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'subst' is a predicate with two forms: */
/* 1.) substitute for all occurrences of */
/* an item. */
/* 2.) substitute for the first N */
/* occurrences on an item. */
/* */
/* form 1 takes arguments: */
/* subst(Item, replacement, List, Result). */
/* form 2 takes arguments: */
/* subst(Item, replacement, List, N, Result).*/
/* */
/* Form 1 is from Clocksin and Mellish p 151 */
/* */
/* E. Lagache, Vers. - 1.00, Dec - 86 */
/* * * * * * * * * * * * * * * * * * * * * * * */
/*** FORM-1 ***/
subst(_,_,[],[]). /* Base case: no list to substitute in */
/* found an occurrence, remove item */
subst(Item, Repl, [Item|List], [Repl|Result]):- !, subst(Item,Repl,List,Result).
/* 'Head' not item, so copy to 'Result' list */
subst(Item, Repl, [Head|List], [Head|Result]):- !, subst(Item,Repl,List,Result).
/*** FORM-2 ***/
subst(_,_,Result,0,Result):- !./* Base case 1: subst correct number of times */
subst(_,_,[],_,[]):- !. /* Base case 2: no list to subst from */
/* found an occurrence, remove item and decrement counter */
subst(Item,Repl,[Item|List],N,[Repl|Result]):- !, Next is N-1,
subst(Item,Repl,List,Next,Result).
/* 'Head' not item, so copy to 'Result' list */
subst(Item,Repl,[Head|List],N,[Head|Result]):- !,subst(Item,Repl,List,N,Result).
/* * * * * * * * * * * * * * * * * * * * * * * */
/* 'sumlist' returns the summation of all */
/* numbers on list 'list'. Predicate returns */
/* false if list contains atoms that are not */
/* numbers. */
/* */
/* E. Lagache, Vers. - 1.00, Dec - 86 */
/* * * * * * * * * * * * * * * * * * * * * * * */
sumlist([],0). /* Base case */
sumlist([Number|Tail],Result):- sumlist(Tail,OldResult),
Result is Number + OldResult.
/* End file: STDLIST.PRO */
------------------------------
End of PROLOG Digest
********************
∂25-Sep-87 1517 @score.stanford.edu:WALESON@SUMEX-AIM.STANFORD.EDU KSL OPEN HOUSE
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 25 Sep 87 15:16:59 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Fri, 25 Sep 87 15:01:45 PDT
Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Fri 25 Sep 87 15:11:07-PDT
Date: Fri, 25 Sep 87 15:05:50 PDT
From: Anthea Waleson <WALESON@sumex-aim.stanford.edu>
Subject: KSL OPEN HOUSE
To: ksl@sumex-aim.stanford.edu, faculty@score.stanford.edu
Cc: waleson@sumex-aim.stanford.edu
Message-Id: <12337524433.89.WALESON@SUMEX-AIM.STANFORD.EDU>
On Tuesday, September 29, there will be an open house at the
Knowledge Systems Laboratory to welcome new students. CS faculty
members, as well as all members of the KSL are invited to attend
and welcome the newcomers.
From 3:30 until 4:00, there will be a brief introduction to the KSL
in the Welch Road conference room designed especially for new students.
A wine and cheese reception for the new students and everyone else
will begin at 4:00. During the reception, some current KSL students
will be describing ongoing projects.
We hope to see you at the KSL on Tuesday, Sept. 29.
-------
∂25-Sep-87 1719 @score.stanford.edu:WALESON@SUMEX-AIM.STANFORD.EDU KSL OPEN HOUSE
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 25 Sep 87 17:16:53 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Fri, 25 Sep 87 17:02:25 PDT
Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Fri 25 Sep 87 16:45:09-PDT
Date: Fri, 25 Sep 87 16:47:16 PDT
From: Anthea Waleson <WALESON@sumex-aim.stanford.edu>
Subject: KSL OPEN HOUSE
To: faculty@score.stanford.edu
Cc: waleson@sumex-aim.stanford.edu
Message-Id: <12337542897.89.WALESON@SUMEX-AIM.STANFORD.EDU>
I understand that there's a CSD faculty meeting at 2:30 on
Tuesday. The RECEPTION part of the reception doesn't begin
until 4:00. Please feel free to come when the faculty meeting
adjourns. Things will probably be running late anyway.
-------
∂25-Sep-87 1730 NILSSON@score.stanford.edu faculty mtg
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 25 Sep 87 17:30:17 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Fri, 25 Sep 87 17:11:21 PDT
Date: Fri 25 Sep 87 17:08:55-PDT
From: Nils Nilsson <NILSSON@score.stanford.edu>
Subject: faculty mtg
To: faculty@score.stanford.edu
Message-Id: <12337546839.36.NILSSON@Score.Stanford.EDU>
We will have a Computer Science Department faculty meeting beginning
promptly at 2:30 p.m. on Tuesday, September 29, in AEL 109 (MJH 146 is
unavailable that day. AEL is just west of the McCulloch building and
south of ERL.)
The agenda will include the following items
(not necessarily in order):
0. Introduction of new faculty and staff
1. Approval of degree candidates
2. Discussion of future faculty hiring priorities
3. Reappointments of consulting/courtesy faculty
4. Policy on keys to MJH for undergraduates
5. Policy on appointments of lecturers
6. Progress on NWC building plan
7. Associate Chair appointment progress
8. Library plans
9. SOE plans for programs in manufacturing
10. Possible new Professors (Research)
11. Reports
CSD-CF, Finance, Forum, Education, ...
If you have additional agenda items to propose, please send them to
Anne Richardson (richardson@score).
Since many of our faculty are on leave or sabbatical this quarter,
it will be important for all those who are in town to attend.
-Nils
-------
∂28-Sep-87 0135 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #67
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Sep 87 01:35:08 PDT
Date: Sun 27 Sep 1987 15:00-PDT
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #67
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Monday, 28 Sep 1987 Volume 5 : Issue 67
Today's Topics:
Implementation - call/N
----------------------------------------------------------------------
Date: Sat, 26 Sep 87 15:40:33 PDT
From: Richard A. O'Keefe <quintus!cresswell!ok@Sun.COM>
Subject: The call/N family.
In the documentation for Lagache's regrettable library, he says of
call/1 that
Older PROLOGs require the 'call' predicate whenever
goals are constructed using '=..'. In order to
maintain compatibility with these old PROLOG[sic]
it is advisable to use 'call' even when it isn't
required by your PROLOG. ... Eventually, as these
older PROLOGs become extinct, this predicate will
be eliminated.
There are several points to note about this.
First, from very early DEC-10 Prolog days, "X" has been accepted as a
goal equivalent to "call(X)". EVERY PROLOG which claims to be in the
"Edinburgh" family should act like this. Certainly, the following
Prologs do:
DEC-10 Prolog
PDP-11 NU7 Prolog
EMAS Prolog
C Prolog (all versions)
POPLOG
LM-Prolog
IF Prolog
BIM Prolog
Arity Prolog
ALS Prolog
Quintus Prolog
Xerox Quintus Prolog
Note that LM-Prolog isn't even in the Edinburgh family. Failure of a
Prolog system to handle the goal "X" as "call(X)" is not a sign of
age: it is a sign that the implementors just couldn't care less about
compatibility.
The second point is that a Prolog programmer who cares about
efficiency will almost NEVER use univ (=..). This piece of advice is
unfortunately system-dependent". In those Prolog systems such as
micro-PROLOG or LM-Prolog where there is only one functor (./2) univ
and = tend to have the same implementation. The LM-Prolog manual
explicitly states that "=.." is equivalent to "=". In interpreted
Prolog systems, univ, though intrinsically inefficient, may be
hand-coded faster than anything you could write in Prolog. But in a
compiled Prolog system such as DEC-10 Prolog, ALS Prolog, or Quintus
Prolog, univ is typically defined in Prolog, using functor/3 and
arg/3.
Thus, if you have a predicate name in the atom P, and two arguments X
and Y, the most efficient way of calling P with those arguments is to
code
functor(Goal, P, 2),
arg(1, Goal, X),
arg(2, Goal, Y),
call(Goal)
A smart compiler (such as the current Quintus Prolog compiler) will
optimise calls to univ with an explicit list, so that
Goal =.. [P,X,Y],
call(Goal)
will produce this effect.
Oh yes, the reason why univ is intrinsically inefficient is that it
involves constructing a list that you don't really want. It takes
time to make the list and more time to garbage collect it. You are
better off not making it in the first place, EXCEPT in those systems
where =.. and = are identical.
But the reason that call/1 isn't going to go away is that far and away
the clearest way of expressing "call P with arguments X and Y"
is to use the predicate call/3, thus:
The public-domain library file ARG.PL held at Stanford defines
call(Pred, Arg1)
call(Pred, Arg1, Arg2)
call(Pred, Arg1, Arg2, Arg3)
call(Pred, Arg1, Arg2, Arg3, Arg4)
Why would one use these?
(1) Clarity.
The details of how the goal is constructed are of no interest to
the reader. Using call/N makes it instantly obvious that what is
going on is a call of a dynamically bound predicate, not the
construction of a data structure.
(2) Implementation independence.
Since the method of constructing the actual goal is concealed,
whatever method is most efficient for the particular Prolog system
can be used. The implementation might use univ, or it might use
the code in the existing APPLY.PL library file, or it might be
built in at micro-code level.
(3) Generality.
I'll get onto this in a minute.
There is one other point, which is whether it is better to write
call(Pred, Arg1, Arg2)
or to write
Pred(Arg1, Arg2)
It is important to realise that this is ONLY a syntax issue. (I am
assuming here a conventional Prolog rather than a sound implementation
TOKENS.PL
+ READ.PL
used to map the source term
Pred(Arg1, Arg2)
for Pred a variable, to the actual term
apply(Pred, [Arg1,Arg2])
To have it produce
call(Pred, Arg1, Arg2)
instead, the first clause of read/5 should read
read(var(Variable,_), ['('|S1], Precedence, Answer, S) :- !,
read(S1, 999, Arg1, S2),
read_args(S2, RestArgs, S3), !,
Term =.. [call,Variable,Arg1|RestArgs],
exprtl0(S3, Term, Precedence, Answer, S).
(This is one of the few occasions where =.. is useful: we do not know
how long RestArgs is.)
I personally find that writing 'call' explicitly is MUCH clearer than
writing a variable in predicate position, especially given the number
of Prolog systems (such as BIM Prolog) which feature upper-case
constants.
But whether one writes call(P,X,Y) or P(X,Y), the operation has to
exist for you to use it, so what harm is there in giving it a name?
To return to point (3): generality. There is a very important
difference between
call(Pred, X, Y)
and Goal =.. [Pred,X,Y], call(Goal).
The difference is that if you use univ explicitly, Pred can ONLY be an
atom! Now that is a very strange and VERY severe restriction. call/1
will accept any callable term as its first argument, not just an atom.
So should EVERY memory of the call/N family. And the public version
of APPLY.PL has always supported this. The rule is that the extra
arguments go at the end.
Let me give you an example to show you how this is useful. Suppose we
have a predicate maplist/3. Here's the definition (which is also in
APPLY.PL):
maplist(_, [], []).
maplist(Pred, [X|Xs], [Y|Ys]) :-
call(Pred, X, Y),
maplist(Pred, Xs, Ys).
Now, suppose I want to reverse all the elements in a list of lists. I
can do
maplist(reverse, Ls, Rs)
That much could have been done with =.. and meta-call. But suppose I
want to check whether all the elements of a list of lists have a
common prefix, and to extract that prefix. I can do
maplist(append(CommonPrefix), Remnants, Lists)
Here's a transcript:
| ?- maplist(append(C), Remnants, [[a,b,c],[a,b,l,e],[a,b,b,o,t]]).
Remnants = [[a,b,c],[a,b,l,e],[a,b,b,o,t]]
C = [] ;
Remnants = [[b,c],[b,l,e],[b,b,o,t]]
C = [a] ;
Remnants = [[c],[l,e],[b,o,t]]
C = [a,b] ;
no
THE ABILITY TO PASS COMPOUND TERMS TO call/N in PROLOG
IS THE EQUIVALENT OF CLOSURES IN LISP.
It is interesting to note that Lagache's quicksort/3 not only violates
the convention of putting meta-arguments first, but is quite
pointlessly restrictive in forcing the meta-argument to be an atom
rather than a closure.
Here is his code, rearranged to be readable:
quicksort(Unsort, Pred, Result) :-
quisort2(Unsort, Pred, Result, []).
quisort2([Item|Tail], Pred, Sort, Partial1) :-
split2(Item, Tail, Pred, Part1, Part2),
quisort2(Part2, Pred, Partial2, Partial1),
quisort2(Part1, Pred, Sort, [Item|Partial2]).
quisort2([], _, Sort, Result) :- !,
Sort = Result.
split2(Item, [Head|List], Pred, Small, [Head|Big]) :-
Test =.. [Pred, Head, Item],
call(Test),
split2(Item, List, Pred, Small, Big).
split2(Item, [Head|List], Pred, [Head|Small], Big) :-
Test =.. [Pred, Head, Item],
not(call(Test)),
split2(Item, List, Pred, Small, Big).
split2(_, [], _, [], []).
[By the way, when WILL people realise that quick sort is NOT a good
sorting method for Prolog? It was included in Clocksin & Mellish as
an example of how to use DIFFERENCE LISTS, not as an example of how to
sort! merge sort is MUCH better for Prolog.]
The following changes should be made.
(1) The convention of putting meta-arguments first should be followed.
This convention applies only to the interface level, not to the
auxiliary predicates.
(2) The comparison predicate should resemble the built-in predicate
compare/3. Indeed, it should be possible to pass compare/3 to the
generalised sorting routine and obtain the special case.
(3) The call/N family should be used rather than univ.
We obtain
quick_sort(Comparison, Input, Output) :-
quick(Input, Comparison, Answer, []),
Output = Answer.
quick([], _, Answer, Answer).
quick([Head|Tail], Comparison, Answer0, Answer) :-
partition(Tail, Head, Comparison, Less, Equal, Answer2, Greater),
quick(Less, Comparison, Answer0, [Head|Equal]),
quick(Greater, Comparison, Answer2, Answer).
partition([], _, _, [], E, E, []).
partition([Head|Tail], Parting, Comparison, L, E0, E, G) :-
call(Comparison, Rel, Head, Parting),
partition(Rel, Parting, Comparison, L, E0, E, G, Head, Tail).
partition(<, Parting, Comparison, [Head|L], E0, E, G, Head, Tail) :-
partition(Tail, Parting, Comparison, L, E0, E, G).
partition(>, Parting, Comparison, L, E0, E, [Head|G], Head, Tail) :-
partition(Tail, Parting, Comparison, L, E0, E, G).
partition(=, Parting, Comparison, L, [Head|E0], E, G, Head, Tail) :-
partition(Tail, Parting, Comparison, L, E0, E, G).
{ Oh yes, this version is STABLE, which Lagache's isn't.
That means that you can use this version to sort by several keys,
but you can't use his version that way. It is rather perverse to
offer for general consumption an unstable quadratic sorting
algorithm when the "native" merge sort is stable and N.lgN.
}
Now suppose we have a predicate compare_padded(Pad, Rel, S1, S2)
which compares two constants using a specified pad character. And
suppose that we would like to have a predicate which sorts a list
of constants using a pad character given as parameter. Then we do
sort_padded(Pad, Input, Output) :-
quick_sort(compare_padded(Pad), Input, Output).
I urge Prolog implementors to provide the call/N family,
and Prolog programmers to demand it from their Prolog vendor.
------------------------------
End of PROLOG Digest
********************
∂28-Sep-87 0758 @Sushi.Stanford.EDU:gatech!hubcap!steve%mcnc.org@forsythe.stanford.edu Re: Minimal number of states for finite state machine
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Sep 87 07:58:24 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Mon 28 Sep 87 07:55:06-PDT
Received: by lindy.stanford.edu; Mon, 28 Sep 87 07:55:20 PDT
Resent-From: gatech!hubcap!steve%mcnc.org@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Mon, 28 Sep 87 07:54:01 PDT
Date: 24 Sep 87 19:47:14 GMT
From: gatech!hubcap!steve@mcnc.org ("Steve" Stevenson)
Subject: Re: Minimal number of states for finite state machine
Message-Id: <C104.THEORYNT@ibm.com>
Resent-Date: 28 Sep 1987 10:53:31-EDT (Monday)
Resent-Sender: THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Resent-To: aflb.tn@sushi.stanford.edu
Apparently-To: aflb.tn@sushi.stanford.edu
in article <C102.THEORYNT@ibm.com>, steve@hubcap.clemson.EDU ("Steve" Stevenson)
>
> Is there an efficient algorithm for converting a finite state machine into
> an equivalent machine with a minimal number of states? You may choose the
> objective function.
Unfortunately, the original posting was unclear as to what
I wanted. I'm looking for the absolute minimum and hence either deterministic
~~~~~~~~~~~~~~~~
or nondeterministic, whichever is smaller. The below seems to answer the
query. Thanks to all who responded.
>If the finite state machine is deterministic, there are standard,
>O(n sup 2) algorithms for state minimization; see Hopcroft and Ullman,
>"Introduction to Automata Theory, Languages, and Computation,"
>Addison-Wesley, 1979. If the finite state machine is nondeterministic,
>the proble is PSPACE-complete;
>see Garey and Johnson, "Computers and Intractability," W.H. Freeman, 1979.
>
>David Johnson, AT&T Bell Laboratories
--
Steve (really "D. E.") Stevenson steve@hubcap.clemson.edu
Department of Computer Science, (803)656-5880.mabell
Clemson University, Clemson, SC 29634-1906
∂28-Sep-87 0813 @Sushi.Stanford.EDU:steve%hubcap.clemson.edu@forsythe.stanford.edu Clemson Mini Conference in Discrete Mathematics
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Sep 87 08:13:04 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Mon 28 Sep 87 07:56:56-PDT
Received: by lindy.stanford.edu; Mon, 28 Sep 87 07:57:09 PDT
Resent-From: steve%hubcap.clemson.edu@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Mon, 28 Sep 87 07:55:54 PDT
Date: Wed, 23 Sep 87 10:45:13 edt
From: "Steve" Stevenson <steve%hubcap.clemson.edu@forsythe.stanford.edu>
Subject: Clemson Mini Conference in Discrete Mathematics
Message-Id: <C105.THEORYNT@ibm.com>
Resent-Date: 28 Sep 1987 10:55:17-EDT (Monday)
Resent-Sender: THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Resent-To: aflb.tn@sushi.stanford.edu
Apparently-To: aflb.tn@sushi.stanford.edu
The 2nd Clemson Mini-Conference
on
Discrete Mathematics
The Departments of Computer Science and Mathematical Sciences at Clemson
University, with support from research contracts from the Office of Naval
Research, announce a two day "mini-conference on theoretical, applied and
computational aspects of discrete mathematics. The conference will be
restricted to ten invited forty-minute presentations. The presentations
will be interspersed with twenty minute discussion periods. All persons
with interests in the many areas of discrete mathematics, from either the
mathematical or computer science aspects, are invited to attend.
Scheduled Speakers:
Prof Lowell Beineke, Indiana University
Prof Gary Chartrand, Western Michigan University
Prof E. J. Cockayne, University of Victoria
Prof Mike Fellows, University of Idaho
Prof Ron Gould, Emory University
Prof C. L. Liu, University of Illinois
Dr. F. R. McMorris, Office of Naval Research
Dr Clyde Monma, Bell Communications Research
Prof K. Brooks Reid, Louisiana State University
Prof Neil Robertson, Ohio State University
Prof Peter L. Hammer, RUTCOR, Rutgers University
Contact:
Prof Renu Laskar, Department of Mathematical Sciences
(803) 656-3434
Prof Stephen Hedetniemi, Department of Computer Science
(803) 656-3444
Clemson University,
Clemson, SC 29634
∂28-Sep-87 0826 @Sushi.Stanford.EDU:RIPBC%CUNYVM.BITNET@forsythe.stanford.edu Seminar in Applications of Logic to Computer Science
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Sep 87 08:26:22 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Mon 28 Sep 87 07:58:02-PDT
Received: by lindy.stanford.edu; Mon, 28 Sep 87 07:58:17 PDT
Resent-From: RIPBC%CUNYVM.BITNET@forsythe.stanford.edu
From: RIPBC%CUNYVM.BITNET@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Mon, 28 Sep 87 07:57:10 PDT
Date: Wed, 23 Sep 87 18:08 EDT
Subject: Seminar in Applications of Logic to Computer Science
Message-Id: <C103.THEORYNT@ibm.com>
Resent-Date: 28 Sep 1987 10:56:45-EDT (Monday)
Resent-Sender: THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Resent-To: aflb.tn@sushi.stanford.edu
Apparently-To: aflb.tn@sushi.stanford.edu
SEMINAR IN APPLICATIONS OF LOGIC TO COMPUTER SCIENCE
This seminar meets at the City University Graduate Center, 33 West
42nd Street, New York, room 1223, Tuesdays from 11-12:30 (app). The next
meetings will be:
Sep 29, Melvin Fitting, Kripke's theory of Truth and Belnap
October 6, Terry Langendoen, Co-ordination in Natural Language
October 13, Ken McAloon, Constraint Logic Programming
∂28-Sep-87 0848 GRAD-ADMIN@score.stanford.edu Research Mentor Information
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Sep 87 08:48:34 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Mon, 28 Sep 87 08:34:42 PDT
Date: Mon 28 Sep 87 08:47:14-PDT
From: Sharon Hemenway <Grad-Admin@score.stanford.edu>
Subject: Research Mentor Information
To: faculty@score.stanford.edu
Message-Id: <12338241942.16.GRAD-ADMIN@Score.Stanford.EDU>
It is that time of your to compile information about research groups
into a packet for use by the new Ph.D. students in choosing their
Research Mentors. Rather than asking for new descriptions from
everyone, we are requesting that you made additions/corrections to
your entries from last year. If you were not included in last year's
packet, please submit a whole description. Some time today you will
receive in your mail boxes paper copies of last year's packet. I have
also placed a copy in the file public:mentor-info.txt. If you would
like me to explicitly send you a copy, please let me know (it is quite
lengthy). Please send your changes or new entries to me by Friday,
October 2.
I have appended below Terry Winograd's message of last year in which
he described the Research Mentor concept and outlined the format of
the Research Group descriptions. Thank you for your help.
Date: Thu 18 Sep 86 15:08:48-PDT
From: Terry Winograd <WINOGRAD@CSLI.STANFORD.EDU>
Subject: Assignment of new PhD students to research groups
To: faculty@SU-SCORE.ARPA
cc: cheadle@SU-SCORE.ARPA, WINOGRAD@CSLI.STANFORD.EDU
The assignment of new students to assistantships this year is being
handled differently, as part of our revision of the PhD program. Part of
the new requirements recently approved by the faculty included the
concept of a research mentor for all entering PhD students. The idea is
to have a more cohesive system for getting all new students involved in
some kind of research, regardless of how they are financially supported.
We want them to be associated with a research group that includes
experienced students as well as faculty and/or full-time researchers.
The connection of the student with the group may be in the form of a RA,
where a student is doing a substantial amount of research work with that
group. It may also be that the student is supported by the group, but
devoting primary effort to studying for the Comprehensive Exam. In
still other cases, there will be no money involved (e.g., the student
has a fellowship, or is being supported by departmental funds), but the
group will provide facilities and connections.
It is not assumed that the student's eventual research work will be with
the initial group or faculty member; this is considered a one-year
initial period for finding out what research here is like. On the other
hand, we expect that many students will initially select a group in
their interest area and end up doing research within it.
Soon after the beginning of the quarter, the new students will be given
a packet describing the potential mentors and groups, and on the basis
of this will seek out positions. After an initial period of open
student-initiated matching, we will more actively help in linking up
those who are still unattached. You are of course free to take on as
few or as many new people as you want.
In order to implement this new system, we need the following
information for each potential GROUP (i.e., some faculty members may
have several distinct research groups, and the student should be
associated with a particular one). Mentors can be research associates
as well as regular faculty.
1. Names of faculty member(s) or research associate(s) in charge.
If several are involved, indicate which, if any, is primary.
2. What is the group called?
This does not need to be an official name, just a unique identifier.
3. What is the research?
We need more than a single sentence - a short paragraph is fine. In
the absence of better information we will include your current entry
in the departmental research summary.
4. Funding sources of the group
If you can include the actual grant/contract titles, that is better, but
just names of the granting agencies will do.
5. Structure of the group
Just a few words -- e.g., "Programming is done by small groups (2-3)
working together. The whole group meets once a week to discuss project
details, and the students participate in the weekly BAGLUNCH seminar."
6. How many (paid and unpaid) slots might you have for new students
7. Names of one or two senior students in the group to whom new
students can talk.
This is extremely useful and can save your having to spend time
answering a lot of the stray questions.
We'll compile your answers and distribute them to the students. If we
don't get anything from you by the first Wed. of the quarter (Oct. 1)
the default will be that you are NOT INTERESTED in working with any
incoming students this year.
By the way, the folders of the incoming students are available in Victoria's
office. Feel free to drop by and peruse them at your convenience, at
which time you can give her the answers to the above, if you don't want
to type them.
Thanks for your help. --t
-------
∂28-Sep-87 0934 BARWISE@CSLI.Stanford.EDU Newsletter
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Sep 87 09:34:27 PDT
Date: Mon 28 Sep 87 09:36:29-PDT
From: Jon Barwise <BARWISE@CSLI.Stanford.EDU>
Subject: Newsletter
To: Symbolic@CSLI.Stanford.EDU
cc: SSP-students@CSLI.Stanford.EDU, SSP-faculty@CSLI.Stanford.EDU
Message-ID: <12338250909.19.BARWISE@CSLI.Stanford.EDU>
The following is a longish (two page) newsletter. If you want a hard
copy, one should be available in the SSP office, 62H, later today.
-------------------
Symbolic Systems Program Fall Newsletter
Symbolic Systems Undergraduate Program
A Note from Jon Barwise, Director of SSP:
Welcome back. I hope you all had a good summer.
There have been some changes in the program staff and faculty
over the summer that you should be aware of. First, as most of you
know, Helen Nissenbaum, the Program Coordinator, is on leave this
year. She and her family are spending a year in Jerusalem. She is
being replaced by Dave Hilbert. Dave recently received his Ph.D. in
philosophy, in an area related to the philosophy of psychology.
Last year we only had a secretary two hours a day. This year, thanks
to support from the Dean's office and CSLI, we will have a secretary
full time. The new secretary, replacing Eve Wasmer, is Margie Kuder.
Margie joins us from the Athletic Department.
Margie will be in the office from 8 to 5, except for lunch, when she
runs or swims. Dave will be in the office in the afternoons, except
Fridays, when he leaves early to play volleyball. Stop by and get to
know both of them.
There are four new faculty members this year. David Rumelhart,
Professor in the Psych Department, joins Stanford this year from UCSD.
He is well known for his work in Parallel Distributed Processes. Jim
Greeno, Professor of Education, has come to Stanford from Berkeley.
He is well known for his work in the psychology of cognition, and its
implications for education. Yoav Shoham, Assistant Professor of
Computer Science, joins the faculty from Yale, where he obtained his
degree. He is an expert in AI, with a special interest causality. In
addition, Joe Halpern of IBM, a consulting professor of Computer
Science, has agreed to be a consulting professor of Symbolic Systems.
Joe works in a wide range of areas with the logic of computer science. I
hope you will make an effort to get to know these new faculty. Look
for their courses and take them if you can.
There is also an exciting new course, described below, that was put
together and approved this year. Some of you may be able to use it in
your concentration. Discuss it with your advisor.
Finally there are two contests, one of which might interest you.
These are described at the end of the newsletter.
Again, welcome back, and have a productive year. Let me know if I can
help in any way. -- Jon Barwise
Lunch on the Terrace:
We will be having a lunch for all SSP students on Oct 15 at noon.
This will be a chance for you to meet your fellow SSP students and
exchange horror stories about scheduling the core courses. The lunch
will be held on the terrace behind building 60. More details will
follow in a later announcement.
Student Representative:
Van Henkle (J.JVLH@lear) is this year's student representative to the
program. You can talk to Van if you have suggestions, comments, or
gripes about the program that you want communicated to the faculty,
things that you might not feel like telling us face to face.
New Course:
SSP will be offering a new course this year.
SS 195 -- Microcomputer Programming Project
3-5 units per quarter, for at most nine units
Instructor: Any SSP faculty member
Course Description: Students develop software illustrating concepts
from symbolic systems using facilities at the SyD Student Development
Laboratory. Ideas for programming projects will be generated by
faculty or by students in consultation with SSP faculty. Particularly
appropriate are projects that produce software useful in SSP courses.
Projects will take place under faculty direction.
Prerequisites:
CS106X (or equivalent)
Familiarity with Macintosh, IBM PC, or other microcomputer, highly
desirable (e.g.by completing CS193)
Consent of an SSP faculty advisor. In many cases, this will be someone
from whom the student has taken and SSP course, and the project idea
will grow out of this course.
Approval of basic proposal for software by course instructor, with
the advice of SyD staff. Approval depends on feasibility of the
project, and its educational benefit to the student.
Sign up for SSP 195-xx, where xx is the number assigned to your
faculty advisor. (See SSP office for listing.)
This course offers you some exciting possibilities for working
closely with faculty on things that really interest you. Think
about it as you take courses. Try to ask yourself once a week whether
anything you are learning in an SSP course could be taught better if
there were a piece of software to illustrate some of the ideas.
There is a contest associated with the first year of this course. See
the item at the end of the newsletter.
Course Changes:
Here are a couple of course changes that might be relevant for some
SSP students.
Phil 160A: First-order logic. The fall offering will not be given.
There will be the usual winter 160A, taught by Etchemendy. There may
be another 160A in the spring. A decision will be made about this in
the fall.
Phil 159: Basic concepts of mathematical logic. Jon Barwise will teach this.
The course will be built around Tarski's World and Turing's World,
programs for the Mac developed by Barwise and Etchemendy in cooperation with
the FAD program. In addition, the course will go into the basic mathematical
notions commonly used in the study of symbolic systems.
Math 292A: Model theory of first-order logic. This course will be
taught by Keith Devlin.
Faculty Changes:
Most of you will of heard by now that Tom Wasow is the new Dean of
Undergraduate Studies. We are very happy to have Tom, who has been
one of the driving forces behind the program, in such an important
position. Unfortunately, the university's gain is Symbolic Systems
loss and Tom will no longer be able to maintain as active a role in
the program as he has in the past. He will, however, continue to do
some teaching and a limited amount of advising.
Although we have gained the new faculty introduced by Jon we have lost
(temporarily, we trust) Terry Winograd and Paul Rosenbloom. They are
both on leave this year and will not be available to advise students.
All their advisees should come by the SSP office (60-62H) so that we
can help you find new advisors. The sooner you do this the better.
Co-terminal program?
Van Henkle is working on designing an SSP masters program so that
students in the program have the option of going Co-term. Planning
for this is still highly tentative. If you have ideas about this, or
want to help it happen, talk to Van.
Contests:
Jon Barwise has announced two competitions for this academic year,
each with a cash prize of $300. One is for the best program to arise
out of our new course, SS195, described above. The other is for an
essay on symbolic systems, titled roughly "Information,
Representation, and Intelligence". The essay should be about at
the level of a Scientific American article, and should present a
synthesis of what you have learned about symbolic systems from your
different courses. The goal of the contest is to get a clear
statement of just what Symbolic Systems is all about to pass on to
future majors and potential majors.
The deadline for submissions for the essay contest is May 15, 1988.
The deadline for the microcomputer program contest is August 31, 1988.
In both cases the contests will be judged by an SSP committee. The
committees reserve the right not to award a prize if there are no
suitable entries.
Late Fees:
The university is threatening to get tough on students who are late
turning in their registration commitments or paying their bills. Of
course none of our students would ever miss a deadline but in case you
were contemplating it, beware.
-------
∂28-Sep-87 1346 @Sushi.Stanford.EDU:johnh@src.DEC.COM Computational Geometry Seminar Announcement
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Sep 87 13:45:58 PDT
Received: from src.dec.com by Sushi.Stanford.EDU with TCP; Mon 28 Sep 87 13:43:23-PDT
Received: from jumbo.dec.com by src.dec.com (5.54.4/4.7.34)
id AA07594; Mon, 28 Sep 87 13:43:52 PDT
Received: by jumbo.dec.com (1.2/4.7.34)
id AA24363; Mon, 28 Sep 87 13:44:42 pdt
From: johnh@src.DEC.COM (John Hershberger)
Message-Id: <8709282044.AA24363@jumbo.dec.com>
Date: 28 Sep 1987 1344-PDT (Monday)
To: aflb.su@sushi.stanford.edu
Cc: johnh@src.DEC.COM
Subject: Computational Geometry Seminar Announcement
Announcing the return of the
Computational Geometry Seminar
Leo Guibas will be leading a seminar on computational geometry again this
year. (He is out of town now, so I am making this announcement on his
behalf.) The seminar will meet weekly to discuss current research in the
rapidly growing field of computational geometry. The seminar is open to
all.
The seminar will meet at a time to be decided by the participants. There
will be an organizational meeting at noon this Friday, October 2, in
MJH352. The meeting shouldn't last long, since setting a regular meeting
time is the chief item of business. If you are interested in attending the
seminar, please come on October 2 to help decide when it will be.
--John Hershberger
∂28-Sep-87 1640 RICHARDSON@score.stanford.edu Lunch/Meeting
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Sep 87 16:40:18 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Mon, 28 Sep 87 16:23:31 PDT
Date: Mon 28 Sep 87 16:35:47-PDT
From: Anne Richardson <RICHARDSON@score.stanford.edu>
Subject: Lunch/Meeting
To: faculty@score.stanford.edu
Message-Id: <12338327240.20.RICHARDSON@Score.Stanford.EDU>
Please remember to note that our faculty lunch and our faculty meeting
tomorrow (Tuesday, September 29) will not take place in the usual location.
The lunch will take place in CIS 101 at 12:15.
The meeting will take place in AEL 109 at 2:30.
See you there!
-Anne
-------
∂28-Sep-87 1838 GANGOLLI@Sushi.Stanford.EDU Next two AFLB talks
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Sep 87 18:38:09 PDT
Date: Mon 28 Sep 87 18:36:54-PDT
From: Anil R. Gangolli <GANGOLLI@Sushi.Stanford.EDU>
Subject: Next two AFLB talks
To: aflb.all@Sushi.Stanford.EDU
Office Phone: (415) 723-3605
Message-ID: <12338349287.20.GANGOLLI@Sushi.Stanford.EDU>
THIS WEEK'S AFLB SEMINAR:
1-October-87: Andrew Goldberg (Stanford)
A Very Simple Algorithm for
the Minimum-Cost Circulation Problem
A classical algorithm for finding a minimum-cost circulation consists
of repeatedly finding a residual cycle of negative cost and canceling
it by pushing enough flow around the cycle to saturate an arc. We
show that a judicious choice of cycles for canceling leads to a
polynomial bound on the number of iterations in this algorithm. This
gives a very simple strongly polynomial algorithm that uses no
scaling. A variant of the algorithm that uses dynamic trees runs in
O(nm log n * min{log (nC),m log n}) time on a network of n
vertices, m arcs, and arc costs of maximum absolute value C. This
bound is comparable to those of the fastest previously known
algorithms.
Joint work with Robert Tarjan (Princeton and Bell Labs.).
***** Time and place: Thurs, October 1, 12:30pm in MJH 352 (Bldg. 460) *****
NEXT WEEK'S AFLB SEMINAR:
8-October-87: Marek Karpinski (Univ. of Bonn, IBM Almaden)
The Parallel Complexity
of Perfect Matching Problems
We construct fast parallel algorithms for deciding, constructing, and
enumerating all the perfect matchings in bipartite graphs with
polynomially bounded permanents. Some implications towards the
parallel complexity of general matching and counting problems are
formulated.
***** Time and place: Thurs, October 8, 12:30pm in MJH 352 (Bldg. 460) *****
-------
∂29-Sep-87 0341 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #68
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Sep 87 03:41:36 PDT
Date: Mon 28 Sep 1987 10:26-PDT
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #68
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Tuesday, 29 Sep 1987 Volume 5 : Issue 68
Today's Topics:
Implementation - Standards & Library & Good Clean Fun
----------------------------------------------------------------------
Date: 27 Sep 87 04:28:45 GMT
From: Lee Naish <munnari!mulga!lee@uunet.uu.net>
Subject: Standard of code
Virtually every time someone posts Prolog code to the network I groan.
I see code like this:
>merge([],[],[]).
>merge([],List2,List2):- !, fail.
>merge(List1,[],List1):- !, fail.
>merge([Head1|Tail1],[Head2|Tail2],[Head1,Head2|R]):- merge(Tail1,Tail2,R), !.
I wince, I tear my hair out, I fall to my knees and bang my head
against the nearest rock crying; is this the Prolog code people write?
What happened to logic programming? Am I wasting my time?
Then I compose myself. I grit my teeth, take hold of my electronic
butchers knife and attack the code. Out with the filth! Out with the
cuts, the dirty negation, the asserts. Wash it clean. Just leave the
essence; pure beautiful logic:
merge([],[],[]).
merge(Head1.Tail1, Head2.Tail2, Head1.Head2.R) :-
merge(Tail1,Tail2,R).
Then I look on it anew. I see it can be run as Prolog. No choice point
will be created! It will be fast! It can be run backwards! It can be
run any way need dictates. I breath a sigh of relief and my confidence
in logic programming and Prolog are restored.
------------------------------
Date: 28 Sep 87 15:54:55 GMT
From: Stanley Shebs <shebs@cs.utah.edu>
Subject: Standard of code
I must be too old and cynical - whenever I see really bad code, my
main regret is that the authors are not in a class I'm teaching, so I
can fail them on that program. (We have used large red stamps saying
"VOMIT" to good effect, also...)
I would like to see next editions of Prolog textbooks flush all the
hype about Prolog being "declarative" (whatever that's supposed to
mean) and replace it with sections on good style. I would like even
more to see cuts disappear from implementations entirely, to be
replaced by meta-level capabilities, but I suppose that's a forlorn
hope, since everybody wants "efficiency".
-- Stan Shebs
------------------------------
Date: Sat, 26 Sep 87 17:36:26 PDT
From: Richard A. O'Keefe <quintus!cresswell!ok@Sun.COM>
Subject: Lagache library.
I'd like to comment on three of the predicates in STDLIST.PRO
sumlist/2
---------
(1) This predicate is in the public-domain library file LISTS.PL
held at Stanford, is it not?
(2) Lagache's definition is not as efficient as it could be.
It does not use tail recursion, so to add up a list of N
numbers it will (temporarily) take up O(N) space on the
stack. Not good. Coding something in tail-recursive
form shouldn't hurt in any bearable Prolog, and it is a
MAJOR improvement in any good Prolog.
His code was
sumlist([], 0).
sumlist([Number|Tail], Result) :-
sumlist(Tail, OldResult),
Result is Number+OldResult.
Better code would be
sumlist(Numbers, Sum) :-
sumlist(Numbers, 0, Sum).
sumlist([], Sum, Sum).
sumlist([Number|Numbers], Sum0, Sum) :-
number(Number),
Sum1 is Sum0+Number,
sumlist(Numbers, Sum1, Sum).
Note that his documentation says that "The predicate will
fail if it is given a list that contains objects that are
not numbers". In most Prolog systems that I know of this
isn't quite true, for one of two opposing reasons:
(a) Some Prolog systems (such as C Prolog or ALS Prolog)
will allow source variables in an arithmetic expression
to be bound to arbitrary arithmetic expressions at run
time. Thus in C Prolog Lagache's code would claim that
| ?- sumlist([1+2,3*4], 15).
But neither 1+2 and 3*4 are compound terms, not numbers.
(b) Some Prolog systems (such as DEC-10 Prolog) will not
allow source variables in an arithmetic expression to
be bound to anything but a number at run time, and will
report violations of this restriction as an error. In
such a system,
| ?- sumlist([a,b,c], X).
will not simply fail, but will do whatever the system
does for errors.
To actually make the code do what Lagache says it does, you
have to insert the number/1 test. The code in LISTS.PL did
not make this test, but the documentation explicitly warned
that the behaviour was undefined on anything but a list of
integers.
One objection to the tail recursive form is that you need
two predicates. Actually, once you get used to it, you'll
very often find that the version with the accumulator is
nearly as useful as the original, because you can "start
the function part-way". For example, if I want to force
the result of sumlist to be a floating-point number even
if all the elements of the list are integers, I can call
sumlist(Numbers, 0.0, Sum)
One of the things which you have to know to be a competent
Prolog programmer is the use of accumulator parameters, of
difference structures (same thing only backwards), and how
to exploit last call optimisation (which is to say, what
the standard transliteration of an iterative loop into the
recursive style of Prolog looks like).
flatten/2
---------
(1) This predicate appears in the public-domain library file FLAT.PL
held at Stanford. However, the version there is an instance of
the generic predicate binary_to_list/5, which means that it is
not as efficient as it might be.
(2) Lagache's code uses neither tail recursion nor difference lists.
His code was
flatten([], []) :- !.
flatten([Head|T], X) :-
listp(Head),
flatten(Head, Y),
flatten(T, Z),
append(Y, Z, X),
!.
flatten([Head|T], [Head|X]) :-
flatten(T, X),
!.
Oy, is this strange! If I recall correctly, Sterling & Shapiro
discuss list flattening in "The Art of Prolog". That is easily
THE best Prolog textbook currently available. If you can only
afford one Prolog book, buy that one.
Here's my code for flatten/2:
% flatten(ConsTree, FlatList)
% flattens out a tree of cons cells into a list.
% Note that it only works that way around: given a List
% there are infinitely many ConsTrees it could have
% come from, including itself.
flatten(ConsTree, FlatList) :-
flatten(ConsTree, FlatList, []).
flatten([], Flat0, Flat) :- !,
Flat0 = Flat.
flatten([Head|Tail], Flat0, Flat) :- !,
flatten(Head, Flat0, Flat1),
flatten(Tail, Flat1, Flat).
flatten(Other, [Other|Flat], Flat).
There is a subtle difference: according to my definition
flatten(a, X) binds X = [a], whereas according to Lagache's
it fails. I consider this to be a bug in Lagache's version:
since flatten([a], X), flatten([[a]], X), flatten([[[a]]], X)
all bind X = [a], why not flatten(a, X)?
There is an important practical difference: this version
makes NO structure that will not appear in the final result,
whereas Lagache's keeps on copying things.
All of this is not really important. I've been writing Prolog
for nearly 8 years and have never yet found a use for flatten/2,
and I've been writing Lisp longer than that and never found a
use for (flatten -) there either. [The other functions in the
public domain FLAT.PL, such as and_to_list/2, HAVE been of use.]
assoc/3
-------
(1) If you want to associate keys with values, you will find two
useful packages in the public-domain DEC-10 Prolog library
held at Stanford: ASSOC.PL (trees) and MAPS.PL (sequences).
You will also find a predicate keys_and_values/3 in PROJEC.PL
which is similar to Lagache's make_assoc_list/3. More about
that shortly.
(2) Lagache's code was
assoc(_,[],error):- !,fail. /* Base recursive case, No such
element found */
assoc(Item,[Pair|_],Pair):- found_item(Pair,Item). /*
Successful match */
assoc(Item,[_|Rest],Pair):- assoc(Item,Rest,Pair). /*
Continue search */
found_item([Item|_],Item). /* test if 'car' of list is
'Item' */
This time I haven't sanitised it.
Some points to note: "base recursive case" contradicts itself. The
base case is not recursive. The first clause is entirely redundant.
This could be coded directly as
assoc(Key, [Cons|_], Cons) :-
Cons = [Key|_].
assoc(Key, [_|Conses], Cons) :-
assoc(Key, Conses, Cons).
or perhaps more lucidly as
assoc(Key, Conses, Cons) :-
Cons = [Key|_],
member(Cons, Conses).
Note that [X|Y] is a cons cell, not a pair.
And [X,Y] is a (two-element) list, not a pair.
X-Y is a pair.
There are two good reasons for using pairs rather than conses.
(a) The result can be type-checked by the Mycroft&O'Keefe type
checker. Source code for that is available in the public-
domain Prolog library at Stanford, see TYPECH.PL & PROLOG.TYP.
The full report from DAI Edinburgh contains a listing.
We would say
:- type list(T) --> [] | .(T,list(T)). % in PROLOG.TYP
:- type pair(K,V) --> K-V. % in PROLOG.TYP
:- pred keysort(list(pair(K,V)), list(pair(K,V))). % "
:- pred assoc(K, list(pair(K,V)), pair(K,V)).
assoc(Key, [Pair|_], Pair) :-
Pair = Key-_Value.
assoc(Key, [_|Pairs], Pair) :-
assoc(Key, Pairs, Pair).
Using conses instead of pairs basically rules out type
checking. (Turbo Prolog victims note.)
(b) The built-in predicate keysort/2 sorts lists of pairs,
not lists of conses. A moderately common idiom is to
write
:- pred sort_by_separate_keys(list(K), list(V), list(K)).
:- pred sort_aux(list(K), list(V), list(pair(K,V)),
list(V), list(pair(K,V))).
sort_by_separate_keys(RawKeys, RawVals, OrdVals) :-
sort_aux(RawKeys, RawVals, RawPairs, OrdVals, OrdPairs),
keysort(RawPairs, OrdPairs).
sort_aux([], [], [], [], []).
sort_aux([K|Ks], [V|Vs], [K-V|Ps], [W|Ws], [_-W|Qs]) :-
sort_aux(Ks, Vs, Ps, Ws, Qs).
As an example of why keysort/2 is useful, suppose that we want
to know whether a given association list is a partial function.
That is, does each key appear at most once in the list?
The obvious way to code this is
non_redundant([]).
non_redundant([K-_|Pairs]) :-
\+ memberchk(K-_, Pairs),
non_redundant(Pairs).
But this takes O(N↑2) time for a list of N pairs. It is
better to use keysort/2 thus:
non_redundant(RawPairs) :-
keysort(RawPairs, OrdPairs),
\+ append(_, [K-_,K-_|_], OrdPairs).
make_assoc_list/3 has two redundant clauses. In fact, they are
worse than redundant, because they destroy its logical character.
Lagache's code was
make_assoc_list([], [], []).
make_assoc_list([], List2, List2) :- !, fail.
make_assoc_list(List1, [], List1) :- !, fail.
make_assoc_list([Head1|Tail1], [Head2|Tail2], [[Head1,Head2]|R]) :-
make_assoc_list(Tail1, Tail2, R),
!.
I shouldn't have to point out that the cut in the last clause is
useless. Should I?
Non-redundant code would be
make_assoc_list([], [], []).
make_assoc_list([Key|Keys], [Value|Values], [[Key,Value]|Lists]) :-
make_assoc_list(Keys, Values, Lists).
This is similar to keys_and_values/3 in PROJEC.PL:
keys_and_values([], [], []).
keys_and_values([Key-Value|Pairs], [Key|Keys], [Value|Values]) :-
keys_and_values(Pairs, Keys, Values).
The advantages of my version over Lagache's are several:
-- purity. It doesn't use cuts.
-- clarity. It is instantly clear that there are just two cases
which can lead to success. (An induction on any one of the
arguments leads directly to this code.)
-- correctness. My version does indeed define a relation.
Lagache's doesn't.
This last point may need explanation. Suppose someone gives me an
association list, and I want to have the keys and values as
separate lists. (This is actually the use keys_and_values/3 is
optimised for.) Then I can just call
make_assoc_list(Keys, Values, TheListIWasGiven)
At least, I can do that with my definition. If Keys and Values are
variables, as they would be in this case, Lagache's definition will
FAIL unless TheListIWasGiven is empty. Here is a transcript:
| ?- make_assoc_list([a,b], [1,2], X).
X = [[a,1],[b,2]]
yes
| ?- make_assoc_list(X, Y, [[a,1],[b,2]]).
no
What went wrong? The second clause matched, binding
X = [], List2 = Y = [[a,1],[b,2]], and then cut and failed.
Exercise for the reader: use this idea to see how Lagache's
subst/4 can be broken. (Hint: correct optimised code is
subst([], _, [], _).
subst([A|As], Old, [B|Bs], New) :-
( A = Old -> B = New ; B = A ),
subst(As, Old, Bs, New).
Aside from exploiting indexing, what is diferent?
Second hint: the name of the design principle that Lagache's
code violates is "The Principle of Allowed Prophets".)
General remarks.
---------------
Lagache's STDLIST.PRO library shows a strong Lisp influence.
There's no harm in that: I keep saying that Prolog implementors
should look to Common Lisp for ideas. But Lagache has followed
his Lisp originals too slavishly. The following criticisms
apply to nearly everything in that library, with the exception
of operations like member/2 and append/3 which have previously
been published:
(1) Failure to exploit tail recursion optimisation.
(2) Many of the predicates are defined so that they can only
work one way around. For example, get_head/3 could have
been defined to fail when the list was too short, and in
that case it could have been implemented reversibly.
(3) Many of the predicates are implemented so that they will
only work one way around, when it would be easy to code
them so that they implement a logical relation. A good
example is reverse/2. A trivial change would make it
fully reversible, but as written it is backwards-incorrect.
(4) More generally, many of the predicates don't do exactly
what the documentation says they do: there are unstated
preconditions.
(5) There are a lot of :- !, fail clauses which are harmful.
And so on.
------------------------------
End of PROLOG Digest
********************
∂29-Sep-87 1502 KUDER@CSLI.Stanford.EDU Oct 12 and l5
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Sep 87 15:02:03 PDT
Date: Tue 29 Sep 87 14:58:08-PDT
From: Margie Kuder <KUDER@CSLI.Stanford.EDU>
Subject: Oct 12 and l5
To: SSP-faculty@CSLI.Stanford.EDU
Message-ID: <12338571607.13.KUDER@CSLI.Stanford.EDU>
Jon Barwise has invited you all to two exciting events the week of Oct.12:
Oct 12 at noon - We are hosting a lunch at the faculty club for you.
We would like you all to come and get to know each
other and enjoy lunch together
Oct 15 at noon - Lunch on the terrace for the SSP students to get aquainted
with you and each other. We will have it at the
patio behind building 60, next to the church.
We really want you to come to these lunches - we hope they fit into
your schedule. Please rsvp to Margie Kuder as soon as possible.
Thank you.
-------
∂29-Sep-87 1519 @score.stanford.edu:MUMICK@Sushi.Stanford.EDU CSD Reception
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Sep 87 15:19:49 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Tue, 29 Sep 87 15:04:58 PDT
Received: from Sushi.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 29 Sep 87 15:17:27-PDT
Date: Tue 29 Sep 87 15:11:16-PDT
From: Inderpal Singh Mumick <MUMICK@sushi.stanford.edu>
Subject: CSD Reception
To: faculty@score.stanford.edu, staff@score.stanford.edu
Office: MJH 460, 723-4096
Residence: 438 Ventura Ave, Apt #2, Palo Alto, CA 94306. 494-8404
Message-Id: <12338573999.24.MUMICK@Sushi.Stanford.EDU>
You are invited to the annual CSD reception, this Thursday, Oct 1, at
4:00 pm, in the MJH/Jordan basement patio.
As usual there will be excellent food catered by Sako, with soft drinks,
juices and beer to accompany.
The CSD prizes will also be given out at the reception.
There will be a volleyball game to follow at 5:30 pm.
Inderpal
-------
∂29-Sep-87 1742 @score.stanford.edu:LES@SAIL.STANFORD.EDU CS 300 Department Lecture Series
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Sep 87 17:42:38 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Tue, 29 Sep 87 17:23:09 PDT
Received: from SAIL.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Tue 29 Sep 87 17:35:31-PDT
Date: 29 Sep 87 1735 PDT
From: Les Earnest <LES@sail.stanford.edu>
Subject: CS 300 Department Lecture Series
To: faculty@score.stanford.edu
Leaders of research projects who would like to interest new students in
their work are invited to give a talk in the CS 300 lecture series, which
occurs on Thursdays from 4:15 to 5:30 in 320-334. Please send me your
topic and any date preferences or impossibilities.
Les Earnest
∂29-Sep-87 1942 @score.stanford.edu:dill@amadeus.stanford.edu Re: CS 300 Department Lecture Series
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Sep 87 19:42:16 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Tue, 29 Sep 87 19:27:46 PDT
Received: from amadeus.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 29 Sep 87 19:40:14-PDT
Received: by amadeus.stanford.edu; Tue, 29 Sep 87 19:46:43 PDT
Date: Tue, 29 Sep 87 19:46:43 PDT
From: David Dill <dill@amadeus.stanford.edu>
Subject: Re: CS 300 Department Lecture Series
To: LES@sail.stanford.edu, faculty@score.stanford.edu
I would like to give a talk. As of now, any day is ok -- but I would
like a week's notice.
- David Dill
∂29-Sep-87 1951 HADDAD@Sushi.Stanford.EDU BATS: call for speakers.
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Sep 87 19:51:38 PDT
Date: Tue 29 Sep 87 19:51:16-PDT
From: Ramsey Haddad <HADDAD@Sushi.Stanford.EDU>
Subject: BATS: call for speakers.
To: aflb.su@Sushi.Stanford.EDU
Message-ID: <12338624971.10.HADDAD@Sushi.Stanford.EDU>
The next BATS will be on Thursday, November 12 at Berkeley. Anyone
from Stanford who would like to speak should send me a note with a
title and abstract within the next week or so.
For those of you who are new, BATS stands for Bay Area Theory Seminar.
It is participated in by people from Stanford, UC Berkeley, IBM
Almaden, DEC SRC, UC Santa Cruz, Xerox PARC and SRI. It rotates
between being held at those institutions (mainly the first four
mentioned). Typically there are four talks: one at 10AM, 11AM, 1PM
and 2PM, with a lunch at noon supplied by the host institution.
The talks cover a variety of topics in theoretical computer science
including Complexity Theory, Coding Theory, Algorithms and Data
Structures, Parallel Computation, etc...
-------
∂30-Sep-87 0009 SF@CSLI.Stanford.EDU Seminar in Logic at Stanford
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Sep 87 00:09:43 PDT
Date: Wed 30 Sep 87 00:11:53-PDT
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: Seminar in Logic at Stanford
To: logmtc@Sail.Stanford.EDU
Message-ID: <12338672413.20.SF@CSLI.Stanford.EDU>
Seminar in Logic and Foundations of Mathematics
First Meeting 1987-1988
Monday Oct.5, 4:15 PM, Room 383N
(3d floor lounge, Math Bldg, Stanford)
Speaker: Prof. Jacques Stern, Mathematiques, Universite de Paris VII
Title: "Equivalence relations on lattices and the complexity of the
theory of permutations which commute."
Abstract (of an abstract): A result on a certain class of equivalence
relations on integer lattices is used to bound the complexity of a
decision procedure for the theory of infinitely many permutations
which commute.
We plan a dinner out for participants following the talk.
*****
After the first meeting, the seminar this quarter will be devoted to the
general subject of applications of logic to computation theory. Among
topics to be discussed are:
1. Inductive definitions, generalized recursion theory and an intensional
theory of algorithms.
2. Uniform inductive definitions and computable data base queries.
3. Relations between logical clasifications of finite models and
complexity classifications of algorithms.
*****
If you want your name added to or removed from LOGMTC@SAIL, communicate
with CLT@SAIL.STANFORD.EDU .
S. Feferman
-------
∂30-Sep-87 0157 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #69
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Sep 87 01:57:42 PDT
Date: Tue 29 Sep 1987 13:40-PDT
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #69
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Wednesday, 30 Sep 1987 Volume 5 : Issue 69
Today's Topics:
Query - HP 9000,
Implementation - Erratum & Standards
----------------------------------------------------------------------
Date: 28 Sep 87 17:51:13 GMT
From: Anne Louise Gockel <vax1!ag4@cu-arpa.cs.cornell.edu>
Subject: CProlog for a HP 9000 running HP-UX
I am naively trying to compile CProlog 1.5 on the Hewlett-Packard HP
9000 which runs HP-UX. HP-UX is a System V based Unix. The HP-UX C
compiler chokes on several constructions that the Mt. Xinu (BSD)
C-compiler allows.
Can anyone tell me where I can find a CProlog that will compile on a
System V machine, or even better under HP-UX? Can anyone tell me
where I can find a more recent version of CProlog?
I am not sure why the BSD C compiler compiles the code that the HP-UX
compiler chokes on. As far as I can see the code is incorrect.
Basically a variable that is defined as 'pointer to a pointer' is
dereferenced. E.G.:
/* The original EMAS Prolog in IMP relies too much on pointers being
just addresses, independently of the type pointed to, for me to be
able to do anything about it. To help satisfy the compiler's view
of typing, addresses are objects of type PTR, which are then cast
into the appopriate types.
*/
typedef unsigned **PTR;
static PTR f, d, b, k, k1, y, p, l, arg1;
.......
if (k->NextVar == NULL ||
(SC(k->NextVar,>=,pauxstk) && SC(k->NextVar,<,ptr))) {
k->VarValue += rglb;
if (k->NextVar) k->NextVar += rauxstk;
k += k->VarLen;
}
In the above code fragment the compiler complains about dereferencing
the variable k. ('Cannot select field of non-structure.' and
'Incompatible types in cast.') SC is a macro that does a
signed-comparison between the 1st and 3rd arguements.
Thank you.
-- Anne Louise Gockel
------------------------------
Date: Mon, 28 Sep 87 14:04:16 PDT
From: Richard A. O'Keefe <quintus!cresswell!ok@Sun.COM>
Subject: Erratum
The "call/N" message I sent was automatically reformatted somewhere
along the way. Amongst other things, this caused the loss of a line.
"I am assuming here a conventional Prolog rather than a sound
implementation"
should read
"I am assuming here a conventional Prolog rather than a
sound implementation OF HIGHER-ORDER LOGIC".
This was followed by
"The public-domain parser held at Stanford in the files
TOKENS.PL
READ.PL"
...
Yes, there is a public-domain parser which is 99.9% compatible with
DEC-10 Prolog. All you need is get0/1, name/2, and (functor/3 and
arg/3 or (=..)/2), and away you go!
------------------------------
Date: 29 Sep 87 03:31:47 GMT
From: Saumya Debray <debray@arizona.edu>
Subject: Standard of code
You can't fault people for wanting efficiency. You *can*, however,
fault implementations that rely overmuch on cuts for performance (I
guess most current implementations would end up being faulted: for
example, how many commercial Prolog systems out there would recognize
that, given the mode <+,+,-,-> for the predicate
part([],_,[],[]).
part([E|L], M, [E|U1], U2) :- E =< M, part(L,M,U1,U2).
part([E|L], M, U1, [E|U2]) :- E > M, part(L,M,U1,U2).
there's no need to create choice points for it? None that I'm aware
of! [*]). Hopefully, as compilers improve, cuts will become less
essential for good performance.
Talking about implementations, I was quite surprised to see, at SLP 87
earlier this month, at least two high-powered commercial Prolog
systems suffer a factor of 3 slowdown when I changed append/3 from
append([],L,L).
append([H|L1], L2, [H|L3]) :- append(L1, L2, L3).
to
append([],L,L).
append([H|L1], L2, L) :- L = [H|L3], append(L1, L2, L3).
Their performance, on naive reverse on a Sun-3/75, dropped from about
140 KLIPS for the "usual" append to about 40 KLIPS for my "mutant"
append. You think people would do a better job of handling
inline predicates and temporaries!
-----
[*] Some versions of SB-Prolog recognize that no choice point need be
created in this case. Of course, SB-Prolog isn't a commercial system.
-- Saumya Debray
------------------------------
End of PROLOG Digest
********************
∂30-Sep-87 1101 @score.stanford.edu:ball@navajo.stanford.edu CSD-CF RATES
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Sep 87 11:00:57 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Wed, 30 Sep 87 10:42:18 PDT
Received: from navajo.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 30 Sep 87 10:19:01-PDT
Received: by navajo.stanford.edu; Wed, 30 Sep 87 10:15:51 PDT
Date: Wed, 30 Sep 87 10:15:51 PDT
From: James E. Ball <ball@navajo.stanford.edu>
Subject: CSD-CF RATES
To: CSD-LIST@score.stanford.edu
From ball Wed Sep 30 09:51:56 1987
Received: by navajo.stanford.edu; Wed, 30 Sep 87 09:51:51 PDT
Date: Wed, 30 Sep 87 09:51:51 PDT
From: James E. Ball <ball>
Subject: rate memo
To: ball@navajo
Status: R
To all concerned parties,
As we started a new fiscal year on September 1st it was necessary to submit
new rates for CSD-CF services. The attached are the rates submitted but not
yet approved. I will inform you when the rates are approved.
Jim Ball
---------------------------------------------------------------------------
CSD-CF Rates
Computer Science Department Computer Facility
Cost Center Rates
Effective September 1, 1987
A Time B Time C Time
A Time B Time C Time
Weekday hours 8:00-17:59 18:00-23:59 0:00-07:59
Weekend hours 13:00-17:59 18:00-12:59
Rates Full 2/3 of A rate 1/3 of A rate
Score Computer
(DEC20/TOPS20)
Account chg per mo @ 5.00
Connect time hours @ 1.00 0.67 0.33
CPU time Minutes @ 2.35 1.57 0.78
Disk space Mbits/Mo @ 2.11
Sail Computer
(DEC10)/WAITS)
Account chg per mo @ 5.00
Connect time hours @ 1.00 0.67 0.33
CPU time Minutes @ 3.98 2.65 1.32
Disk space Mbits/Mo @ 3.75
Navajo Computer
(VAX-780/UNIX)
Account chg per mo @ 5.00
Connect time hours @ 1.00 0.67 0.33
CPU time Minutes @ 1.89 1.26 0.63
Disk space Mbits/Mo @ 2.94
Labrea Computer
(VAX-750/UNIX)
Account chg per mo @ 5.00
Connect time hours @ 1.00 0.67 0.33
CPU time Minutes @ 1.53 1.02 0.51
Disk space Mbits/Mo @ 0.47
Jeeves Fileserver
(SUN-3/UNIX)
Account chg per mo @ 5.00
Connect time hours @
CPU time Minutes @
Disk space Mbits/Mo @ 1.14
Sushi Computer
(DEC20/TOPS20)
Monthly charges
Maint. & Depr. 8,420.00
Printers
Dovers pages @ 0.09
Imagen/Apple pages @ 0.09
Boise pages @ 0.07
Phototypsetter
Page charges @ 4.50
Ethernet Maintenance
Monthly charges
Workstations & Minis 33.00
Mainframes & Bridges 330.00
VAX-75- Computer Maint.
Monthly charges
Basic VAX-750 475.00
RA81 Disk Drive 100.00
Kennedy 9300 Tape 200.00
Fujitsu M2351 Disk 50.00
TU78 100.00
CDC 9766 Controller 100.00
Emulex SC758 66.00
8 line term MUX 16.00
∂30-Sep-87 1631 @score.stanford.edu:MUMICK@Sushi.Stanford.EDU CSD Reception
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Sep 87 16:30:57 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Wed, 30 Sep 87 16:17:25 PDT
Received: from Sushi.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 30 Sep 87 16:25:21-PDT
Date: Wed 30 Sep 87 16:25:04-PDT
From: Inderpal Singh Mumick <MUMICK@sushi.stanford.edu>
Subject: CSD Reception
To: faculty@score.stanford.edu, staff@score.stanford.edu,
csd@sushi.stanford.edu
Office: MJH 460, 723-4096
Residence: 438 Ventura Ave, Apt #2, Palo Alto, CA 94306. 494-8404
Message-Id: <12338849578.8.MUMICK@Sushi.Stanford.EDU>
You are invited to the annual CSD reception, this Thursday, Oct 1, at
4:00 pm, in the MJH/Jordan basement patio.
As usual there will be excellent food catered by Sako, with soft drinks,
juices and beer to accompany.
The CSD prizes will also be given out at the reception.
There will be a volleyball game to follow at 5:30 pm.
Inderpal
-------
-------
∂30-Sep-87 1827 OKUNO@SUMEX-AIM.STANFORD.EDU Russ's talk at Parc
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Sep 87 18:26:56 PDT
Date: Wed, 30 Sep 87 18:25:31 PDT
From: Hiroshi "Gitchang" Okuno <Okuno@SUMEX-AIM.STANFORD.EDU>
Subject: Russ's talk at Parc
To: aap@SUMEX-AIM.STANFORD.EDU
Organization: Knowledge Systems Laboratory, CSD, Stanford University
Group: Heuristic Programming Project
Project: Advanced Architectures Project
Address: 701 Welch Road, Building C, Palo Alto, CA 94304-1703
Phone: +1 (415)725-4854
Message-ID: <12338871503.50.OKUNO@SUMEX-AIM.STANFORD.EDU>
If you have a plan to attend just Russ's talk at Parc which starts at
3:15, could you give me a ride? It's a great deal of effort for me to
go there by bike.
Thanks in advance,
- Gitchang -
-------
∂01-Oct-87 0228 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #70
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Oct 87 02:28:47 PDT
Date: Wed 30 Sep 1987 09:36-PDT
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #70
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Thursday, 1 Oct 1987 Volume 5 : Issue 70
Today's Topics:
Implementation - Sour Persimmons,
& List Syntax & Argument Order
----------------------------------------------------------------------
Date: 29 Sep 87 18:05:24 GMT
From: Edouard Lagache <violet.berkeley.edu!lagache@jade.Berkeley.EDU>
Subject: Thanks for the sour persimmons cousins
Well I am certainly glad that at least someone went to the trouble of
actually reading my PROLOG library code (on second thought, maybe it
would have been better otherwise ....)
To be quite honest, I thought that nit-pickers were only to be found in
model railroading and other "precision" hobbies, but I guess the PROLOG
net has its own set, and regrettably, I didn't put a "no nit-picking"
sign on my documentation.
So on to the nit-picks: First, the highly optimal code of Lee Naish
i.e.
merge([],[],[]).
merge(Head1.Tail1, Head2.Tail2, Head1.Head2.R) :-
merge(Tail1,Tail2,R).
does not run on the A.D.A. VML PROLOG interpreter. It complains about
finding "unexpected period on line 2". While I believe the dot
notation for cons cells is part of the original language specification,
it isn't mentioned in Clocksin and Mellish, and thus, is missing from
at least one PROLOG implementation.
As to the complaints on '!,fail' clauses. I too am fully aware that
they are redundant. However, what a computer can easily deduce from
the code, may be difficult for humans to discern, particularly for
those new to PROLOG. While A.I. researchers seem determined to make
their code as cryptic as possible, the rest of the programming world is
still in the midst of a "readability revolution". Given the terseness
of some of the code touted as "improvements" over my work, it may be
time for some people on this net to go back and take a course in
structured Pascal!
Finally, there were a number of important comments that I will keep and
attempt to implement after I complete my Master's Thesis this fall. I
am not a PROLOG guru, and never claimed that I was. Nor was I aware of
what other sorts of public domain PROLOG libraries already existed.
My entire objective was to produce a clean, well documented package of
basic predicates in order to save other programmers from having to re-
invent the wheel. With the help of everyone on the net, these
libraries can be made optimal, and the documentation can be made both
more readable and accurate. However, unless people take a more
constructive and less antagonistic attitude toward contributions, not
only will these libraries die of neglect, but people will simply not
contribute valuable materials to avoid the grief that I have had the
pleasure of enduring!
Edouard Lagache
School of Education
U.C. Berkeley
------------------------------
Date: 30 Sep 87 05:22:46 GMT
From: Lee Naish <munnari!mulga!lee@uunet.uu.net>
Subject: Thanks for the sour persimmons cousins
I think it is unfortunate that there has been so much negative
feedback for Lagache's code. There have been other collections of
code posted to the net (worse than the recent posting, I think) which
people have quietly ignored. Recent postings are a result of long
term frustration, and are not personal attacks. Hopefully people will
learn from these postings (I have).
> merge([],[],[]).
> merge(Head1.Tail1, Head2.Tail2, Head1.Head2.R) :-
> merge(Tail1,Tail2,R).
> does not run on the A.D.A. VML PROLOG interpreter. It complains about
> finding "unexpected period on line 2". While I believe the dot
> notation for cons cells is part of the original language specification,
> it isn't mentioned in Clocksin and Mellish, and thus, is missing from
> at least one PROLOG implementation.
It can be made to run on some Prolog systems which object to it at
first by declaring . as an operator. One thing which has always
puzzled me is why people (even the best Prolog programmers in the
civilized world), insist on using [H|T] instead of H.T and why
implementors support the first syntax more.
H.T is more readable
H.T says the functor is '.' and there are two arguments, H and T
H.T is one less character
H.T doesn't use 'funny' characters used for letters in Europe
H.T is not a syntactic special case (well,.. less so)
[H|T] confuses people. It has confused Prolog implementors! There are
Prolog implementations in which lists are not normal terms, due to this.
Of course it is a shame that '.' and ',' are so overloaded in Prolog,
but since '.' IS the list constructor functor, we may as well get it
out in the open for all to see.
Readability is in the eye of the beholder (see my previous comment).
However, I think it is generally agreed that cut does not aid readability.
An advantage that (clean) Prolog has over Pascal (no matter how structured)
is that it has declarative semantics. People should rediscover this every
few months; one tends to forget.
-- Lee Naish
------------------------------
Date: Tue, 29 Sep 87 00:08:04 PDT
From: Richard A. O'Keefe <quintus!cresswell!ok@Sun.COM>
Subject: Argument order
I have been asked to clarify what I meant by
"the convention of putting meta-arguments first".
One of the problems with Prolog is that a typical predicate
needs rather more arguments than the corresponding function in
Pascal, Lisp, or other imperative languages. The reason for
this is that each non-local constant corresponds to an extra
argument, and each variable updated in a loop corresponds to a
pair of extra arguments. Thus where in C you might write
s = 0;
for (i = N; --i >= 0; ) s += L[i]
in Prolog you would write
p(L, 0, S)
where
p([], S, S).
p([X|Xs], S0, S) :-
S1 is S0+X,
p(Xs, S1, S).
Viewed from a sufficiently great height, these are the same
piece of code.
The more arguments you have, the easier it is to get
confused. So you need some systematic convention for keeping
track of what goes where. This is especially important for the
interfaces of modules or library packages, or in general for
anything that other people are supposed to see.
The fundamental argument order convention in Prolog is
+----------------------------+
| INPUTS BEFORE OUTPUTS |
+----------------------------+
This used to be almost but not quite arbitrary. Given that
people will be reading your code from left to right, pattern
matching on inputs will be seen first, and it will be easier for
someone reading your code to determine how it works if you
follow this convention. Pop-2 programmers will of course agree
totally with this convention, and APL programmers have always
followed it, though they interpret "before" as "to the right
of". However, whether you prefer this order or not, the fact is
that most Prolog systems that provide any kind of indexing
provide it on the first argument (yes, better indexing is
needed) so that if you put inputs before outputs, indexing is
more likely to help you.
But there are other things going on than just simple inputs
and outputs. For example, there are difference lists. More
generally, you may have several arguments that correspond to
positions in a physical or logical sequence. The convention is
that they will be named Foo0, Foo1, ..., Foo (for your choice of
name Foo), and that such of these variables as appear in the
clause head will appear together in logical order. The usual
example of this is DCG rules, where the translation of
p --> q, r.
is
p(S0, S) :- q(S0, S1), r(S1, S).
It usually helps to think of such positions as a single output
which happens to occupy several argument positions.
In the p/3 example above (the guts of sumlist/2), the last
two arguments are an accumulator pair, which should be thought
of as a single output (the number S-S0) which is realised as two
arguments. p/3 thus has its input preceding its output, as it
should.
But inputs come in several flavours. The basic rule is that
they are ordered by degree of inputness. This was how we
originally understood arg/3.
arg(N, Term, Arg)
The third argument is usually thought of as an output. The
first argument must be completely ground, whereas the second
argument need only be instantiated. So the first argument is a
"harder" input than the second. In fact we often use arg/3 to
fill in an argument of a term, so the second argument is a bit
like an output.
A special case of this rule is that I/O operations which take
a parameter identifying the "stream" to be used always have this
parameter first. Such an argument must always be ground, so
this is an instance of "strict inputs before other inputs".
What happens if you have several stream arguments to a single
procedure? (One is bad enough, in all conscience. That could
be the topic of another note.) Well, we can apply the
fundamental rule again, with tongue in cheek.
Input stream arguments come first, then
Output stream arguments, next, then
all the other arguments.
arg/3 has served as the model for a large family of
predicates that notionally fetch some element out of a
collection, or update a collection. The general scheme is
Index < Collection < Element
Hence we have
arg(Index, Term, Argument)
fetch(Index, Array, Element)
get_assoc(Key, AssociationTree, Value)
This even explains member/2
member(Pattern, Collection /* -> true or false */)
What should we do when we are updating a data structure (or
rather, when we are computing a modified one)? Follow the
rules: inputs before outputs, otherwise like selection. So you
might expect
change_arg(Index, OldTerm, NewArgument, NewTerm).
That would make a lot of sense. But it is better to look for a
scheme which is more generally consistent. A point to bear in
mind is that it is useful to think in terms of groups of
arguments. So it is useful to think of a Collection+Element
group, and to try to put a collection and its related element
always in the same order. So we think of it as
change_arg(Index, <old group>, <new group>)
and arrive at
change_arg(Index, OldTerm, NewTerm, NewArg)
and, when you want to express the transformation by pattern
matching on the elements,
change_arg(Index, OldTerm, OldArg, NewTerm, NewArg).
Isn't this a bit artificial? Yes, the whole idea of any sort
of convention is artificial. But remember difference groups.
It is very often useful to think of the Collection and Element
as "positions" in a tree. We think of the entire GROUP
consisting of the Collection and its Element as a single input
or output. The Collection preceding the Element is just like
the Front of a difference list preceding the Back. To point up
the parallel:
path_arg([], Term, Term).
path_arg([Index|Indices], Term0, Term) :-
arg(Index, Term0, Term1),
path_arg(Indices, Term1, Term).
has EXACTLY the same logical structure as
append2([], List, List).
append2([X|Xs], List0, List) :-
List0 = [X|List1],
append2(Xs, List1, List).
What about meta-arguments, though?
A meta-argument is a (possibly incomplete) goal.
Examples are
\+(G), G
setof(T, G, S) G
once(G) G
forall(G1, G2) G1, G2
maplist(P, Xs, Ys) P {will have 2 more arguments}
Now meta-arguments have very much the character of an input. A
Prolog system which could solve for the P argument in a call to
maplist(P, Xs, Ys) would be a very clever system indeed. So
they are a pretty strong sort of input.
maplist/3 CAN solve for its second argument given its third.
But it can't solve for its first. So the meta-argument is
stricter than the list, even though we might be tempted to think
of the second argument as only an input.
It is easily observed that most predicates with a meta-
argument really should put it first by the rules we have already
given. For example, consider a sorting routine.
some_sort(Comparison, Unordered, Ordered)
If the sorting routine resembles keysort/2 rather than sort/2,
we could in principle enumerate the permutations of Ordered and
generate Unordered if we had to. If you think about it, you'll
see that it is easy to compute Ordered given Unordered and
Comparison, easy but impractical to computer Unordered given
Ordered and Comparison, and quite out of the question to solve
for Comparison at all. This observation is generalised to the
convention of putting meta-arguments first.
In fact, I lied to you before. Meta-arguments come even
before streams. A Prolog system has only a smallish number of
streams open at one time, so it could enumerate them. In most
cases, it wouldn't be a good idea, but it could be done. So we
get operations like
Goal with_output_to Stream
Goal with_input_from Stream
One final step will give us all the conventions I know of.
How do setof/3, bagof/3, findall/3, aggregate/3, and so on fit
in? They appear to be exceptional.
This is an arbitrary rule: a Template argument comes first
in its group. We should think of the input to bagof/3 &c as the
group <Template, Generator>. Suppose we had a predicate
modify(OldPattern, Filter, NewPattern, Generator)
which was supposed to replace each instance of OldPattern in the
data base which satisfies Filter by all the instances of
NewPattern that the corresponding instance of Generator
enumerates. This operation has two input groups, in each of
which a Template precedes its Generator.
Templates are meta-arguments in another sense: the effect of
the predicate depends on the instantiation state of the
Template, but the Template will not end up further instantiated
by the call.
So we end up with the convention
+----------------------------------------------------------------+
| Meta-arguments < Streams < Ground inputs < Inputs < Outputs |
+----------------------------------------------------------------+
applying at the group level, and
+----------------------------------------------------------------+
| Selector < Collection < Element |
| Template < Goal |
| Foo0 < Foo1 < ... < Foo |
+----------------------------------------------------------------+
applying within the group level.
These conventions came about the way that the principles of
Jurisprudence came about: trying to make sense of the cases
that already existed. They express the idea "inputs before
outputs" in much the way that the legal system expreses the idea
of justice: imperfectly, but better than nothing.
The advantage of using these conventions is that it makes
coding AND using a package so much easier. As designer, you do
not have to invest a lot of effort in trying to work out which
of 5! argument orders to use (often there will only be one
permitted by the conventions). As coder, you will be able to
remember the order you chose. And as package user, you will not
have to keep referring back to the manual to discover what
argument order the designer chose.
For example, suppose you want an operation which takes a data
structure BigThing, a list of items within it WhichOnes, and a
stream WhereToPutThem, and writes the selected items to the
stream. These conventions don't tell you what it it is called,
but they DO tell you that the order must be
WhereToPutThem, WhichOnes, BigThing
That's (3!-1) cases you didn't need to consider as a designer,
5 mistakes you won't make as a user.
It is worth repeating that it isn't quite so important to
follow these convensions within a package. Shifting the
meta-arguments out of the way so that you can index on something
interesting is a particularly valuable thing to do. But you do
NOT make the users of your package have to guess which way round
you found it most efficient to put things. Don't be afraid of
adding interface predicates such as
quick_sort(Comparison, Input, Output) :-
qs1(Input, Comparison, Output).
It's only a variable shuffle and a jump after all, and it is a
wonderful opportunity to put some error checking code in.
------------------------------
End of PROLOG Digest
********************
∂01-Oct-87 0341 DELAGI@SUMEX-AIM.STANFORD.EDU Re: Russ's talk at Parc
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Oct 87 03:41:09 PDT
Date: Thu, 1 Oct 87 03:40:01 PDT
From: Bruce Delagi <DELAGI@SUMEX-AIM.STANFORD.EDU>
Subject: Re: Russ's talk at Parc
To: Okuno@SUMEX-AIM.STANFORD.EDU
cc: aap@SUMEX-AIM.STANFORD.EDU
In-Reply-To: <12338871503.50.OKUNO@SUMEX-AIM.STANFORD.EDU>
Message-ID: <12338972447.11.DELAGI@SUMEX-AIM.STANFORD.EDU>
and if you're going by car and have room for one more, please let me
know too -- [I'll probably bike but it would be good to know the alternative]
/b
-------
∂01-Oct-87 0505 @score.stanford.edu:MUMICK@Sushi.Stanford.EDU CSD Reception
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Oct 87 05:05:47 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Tue, 29 Sep 87 15:04:58 PDT
Received: from Sushi.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 29 Sep 87 15:17:27-PDT
Date: Tue 29 Sep 87 15:11:16-PDT
From: Inderpal Singh Mumick <MUMICK@sushi.stanford.edu>
Subject: CSD Reception
To: faculty@score.stanford.edu, staff@score.stanford.edu
Office: MJH 460, 723-4096
Residence: 438 Ventura Ave, Apt #2, Palo Alto, CA 94306. 494-8404
Message-Id: <12338573999.24.MUMICK@Sushi.Stanford.EDU>
You are invited to the annual CSD reception, this Thursday, Oct 1, at
4:00 pm, in the MJH/Jordan basement patio.
As usual there will be excellent food catered by Sako, with soft drinks,
juices and beer to accompany.
The CSD prizes will also be given out at the reception.
There will be a volleyball game to follow at 5:30 pm.
Inderpal
-------
∂01-Oct-87 0545 @score.stanford.edu:ball@navajo.stanford.edu CSD-CF RATES
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Oct 87 05:45:11 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Wed, 30 Sep 87 10:42:18 PDT
Received: from navajo.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 30 Sep 87 10:19:01-PDT
Received: by navajo.stanford.edu; Wed, 30 Sep 87 10:15:51 PDT
Date: Wed, 30 Sep 87 10:15:51 PDT
From: James E. Ball <ball@navajo.stanford.edu>
Subject: CSD-CF RATES
To: CSD-LIST@score.stanford.edu
From ball Wed Sep 30 09:51:56 1987
Received: by navajo.stanford.edu; Wed, 30 Sep 87 09:51:51 PDT
Date: Wed, 30 Sep 87 09:51:51 PDT
From: James E. Ball <ball>
Subject: rate memo
To: ball@navajo
Status: R
To all concerned parties,
As we started a new fiscal year on September 1st it was necessary to submit
new rates for CSD-CF services. The attached are the rates submitted but not
yet approved. I will inform you when the rates are approved.
Jim Ball
---------------------------------------------------------------------------
CSD-CF Rates
Computer Science Department Computer Facility
Cost Center Rates
Effective September 1, 1987
A Time B Time C Time
A Time B Time C Time
Weekday hours 8:00-17:59 18:00-23:59 0:00-07:59
Weekend hours 13:00-17:59 18:00-12:59
Rates Full 2/3 of A rate 1/3 of A rate
Score Computer
(DEC20/TOPS20)
Account chg per mo @ 5.00
Connect time hours @ 1.00 0.67 0.33
CPU time Minutes @ 2.35 1.57 0.78
Disk space Mbits/Mo @ 2.11
Sail Computer
(DEC10)/WAITS)
Account chg per mo @ 5.00
Connect time hours @ 1.00 0.67 0.33
CPU time Minutes @ 3.98 2.65 1.32
Disk space Mbits/Mo @ 3.75
Navajo Computer
(VAX-780/UNIX)
Account chg per mo @ 5.00
Connect time hours @ 1.00 0.67 0.33
CPU time Minutes @ 1.89 1.26 0.63
Disk space Mbits/Mo @ 2.94
Labrea Computer
(VAX-750/UNIX)
Account chg per mo @ 5.00
Connect time hours @ 1.00 0.67 0.33
CPU time Minutes @ 1.53 1.02 0.51
Disk space Mbits/Mo @ 0.47
Jeeves Fileserver
(SUN-3/UNIX)
Account chg per mo @ 5.00
Connect time hours @
CPU time Minutes @
Disk space Mbits/Mo @ 1.14
Sushi Computer
(DEC20/TOPS20)
Monthly charges
Maint. & Depr. 8,420.00
Printers
Dovers pages @ 0.09
Imagen/Apple pages @ 0.09
Boise pages @ 0.07
Phototypsetter
Page charges @ 4.50
Ethernet Maintenance
Monthly charges
Workstations & Minis 33.00
Mainframes & Bridges 330.00
VAX-75- Computer Maint.
Monthly charges
Basic VAX-750 475.00
RA81 Disk Drive 100.00
Kennedy 9300 Tape 200.00
Fujitsu M2351 Disk 50.00
TU78 100.00
CDC 9766 Controller 100.00
Emulex SC758 66.00
8 line term MUX 16.00
∂01-Oct-87 1222 EMMA@CSLI.Stanford.EDU CSLI Calendar, Oct. 1, 3:1
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Oct 87 12:22:19 PDT
Date: Thu 1 Oct 87 10:40:25-PDT
From: Emma Pease <Emma@CSLI.Stanford.EDU>
Subject: CSLI Calendar, Oct. 1, 3:1
To: friends@CSLI.Stanford.EDU
Tel: (415) 723-3561
Message-ID: <12339048978.23.EMMA@CSLI.Stanford.EDU>
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
1 October 1987 Stanford Vol. 3, No. 1
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR NEXT THURSDAY, 8 October 1987
3:30 p.m. Tea
Ventura Hall
4:15 p.m. CSLI/Philosophy Colloquium
Philosophy Providing a Rational Basis for Morality
Bldg. 90:91A Holly Smith, Dept. of Philosophy,
University of Arizona
--------------
ANNOUNCEMENT
Fall Seminars, TINLunches, and Colloquia
This fall we are going to try something a bit different for our
Thursday Seminars and and at least some of the TINLunches.
Thursday Seminars will consist mainly of two- or three-week-long
miniseries from key research areas. Each miniseries will be
structured to give CSLI researchers and visiting scholars a clear
picture of progress in that area. Two or three of the lectures in
each series will be followed a week later by a "related TINLunch"
during which people can ask questions and/or continue discussing the
lecture of the previous week.
The CSLI Colloquium Series will be irregular, as it was last year.
--------------
PHILOSOPHY SEMINAR
Seminar on Issues in Logical Theory
Philosophy 396
Tuesdays, 3:15-5:05
Bldg. 90:92Q
Instructor: John Etchemendy
(Etchemendy@csli.stanford.edu)
In this seminar, we will work carefully through the book THE LIAR: An
Essay on Truth and Circularity, by Barwise and Etchemendy. The
seminar may be useful for anyone who either (a) wants an introduction
to some of the basic ideas of situation semantics, (b) is interested
in set-theoretic techniques for modeling nonwellfounded
objects/processes, (c) is interested in the structure of propositions
and information, or -- last and least -- (d) is interested in the
paradox of the liar.
-------
∂01-Oct-87 1242 TAJNAI@score.stanford.edu Seminar on Combinatorics
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Oct 87 12:42:20 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Thu, 1 Oct 87 12:24:59 PDT
Date: Thu 1 Oct 87 12:37:15-PDT
From: Carolyn Tajnai <TAJNAI@score.stanford.edu>
Subject: Seminar on Combinatorics
To: faculty@score.stanford.edu
Message-Id: <12339070248.25.TAJNAI@Score.Stanford.EDU>
Roy Hoyer of the Bookstore needs to know who in CSD is
sponsoring a seminar on 10/20 on combinatorics.
Any one know?
Carolyn
-------
∂01-Oct-87 1425 @score.stanford.edu:JMC@SAIL.STANFORD.EDU visiting professors
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Oct 87 14:25:27 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Thu, 1 Oct 87 14:07:55 PDT
Received: from SAIL.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Thu 1 Oct 87 14:18:37-PDT
Date: 01 Oct 87 1418 PDT
From: John McCarthy <JMC@sail.stanford.edu>
Subject: visiting professors
To: faculty@score.stanford.edu
Cc: richardson@score.stanford.edu
Does anyone have proposals for a visiting professor for next year?
I seem to be in charge of this although away, and I suppose I can
collect proposals and suggestions by email.
∂01-Oct-87 1436 REULING@Score.Stanford.EDU MJH Offices will close early today
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Oct 87 14:36:14 PDT
Date: Thu 1 Oct 87 14:30:48-PDT
From: Yvette Sloan <SLOAN@Score.Stanford.EDU>
Subject: MJH Offices will close early today
Sender: REULING@Score.Stanford.EDU
To: csd-list@Score.Stanford.EDU
Message-ID: <12339090920.19.REULING@Score.Stanford.EDU>
This is to inform you that all offices will close at 4:00 p.m. today. The
occasion is the Departmental Reception for our new students which will be
held outside on the basement patio. Hope to see all of you there!
-------
∂01-Oct-87 1452 @score.stanford.edu:nilsson@Tenaya.Stanford.EDU visiting professors
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Oct 87 14:52:49 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Thu, 1 Oct 87 14:35:36 PDT
Received: from Tenaya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 1 Oct 87 14:35:14-PDT
Received: by Tenaya.Stanford.EDU (3.2/SMI-3.2)
id AA00638; Thu, 1 Oct 87 14:35:35 PDT
Date: Thu, 1 Oct 87 14:35:35 PDT
From: nilsson@tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8710012135.AA00638@Tenaya.Stanford.EDU>
To: JMC@sail.stanford.edu
Cc: faculty@score.stanford.edu, richardson@score.stanford.edu
In-Reply-To: John McCarthy's message of 01 Oct 87 1418 PDT <8710012125.AA00582@Tenaya.Stanford.EDU>
Subject: visiting professors
Maybe Dick Duda (I hear he may be available). -Nils
∂01-Oct-87 1559 @score.stanford.edu:LES@SAIL.STANFORD.EDU CS 300 Schedule
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Oct 87 15:59:14 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Thu, 1 Oct 87 15:40:36 PDT
Received: from SAIL.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Thu 1 Oct 87 15:52:50-PDT
Date: 01 Oct 87 1552 PDT
From: Les Earnest <LES@sail.stanford.edu>
Subject: CS 300 Schedule
To: faculty@score.stanford.edu
Here is a tentative schedule for CS 300 lectures. We seem to have a few more
prospective speakers than dates, so it may be desirable to continue this series
into the Winter Quarter.
Those who are listed below, please verify that the date is OK for you and
mark it on your calendar. Each speaker will be responsible for bringing
any projection equipment that they need to the classroom, which is in Room
320-334 (Geology Corner, same as last year).
Les Earnest
----------------------
DATE SPEAKER TOPIC
10/1 Les Earnest Introduction to Stanford CSD
10/8 Zohar Manna Logic of Programs
10/15 Anoop Gupta Research in Parallel Symbolic Processing
and Computer Architectures
10/22 David Luckham Specification Languages and New
Programming Environments
10/29 David Dill Automatic Verification of Speed-independent
Circuits
11/5 David Ungar Self: a Streamlined Language for
Object-oriented Exploratory Programming
11/12 Yoav Shoham (To be announced)
11/19 Vaughan Pratt Languages for Specifying Information Systems
12/5 Marty Tenenbaum AI in Manufacturing
∂01-Oct-87 1612 HILBERT@CSLI.Stanford.EDU New Symbolic Systems faculty
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Oct 87 16:12:29 PDT
Date: Thu 1 Oct 87 16:07:54-PDT
From: David Hilbert <HILBERT@CSLI.Stanford.EDU>
Subject: New Symbolic Systems faculty
To: ssp-faculty@CSLI.Stanford.EDU, ssp-students@CSLI.Stanford.EDU
Message-ID: <12339108595.50.HILBERT@CSLI.Stanford.EDU>
We are happy to announce that Barbara Tversky and Misha Pavel have
joined the program faculty. Both are in Psychology and have interests
that will complement the program, especially in the area of cognition.
Dave Hilbert
Program Coordinator
-------
∂01-Oct-87 1723 @score.stanford.edu:JMC@SAIL.STANFORD.EDU re: visiting professors
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Oct 87 17:23:08 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Thu, 1 Oct 87 17:17:37 PDT
Received: from SAIL.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Thu 1 Oct 87 17:17:51-PDT
Date: 01 Oct 87 1717 PDT
From: John McCarthy <JMC@sail.stanford.edu>
Subject: re: visiting professors
To: FEIGENBAUM@sumex-aim.stanford.edu
Cc: faculty@score.stanford.edu
[In reply to message sent Thu, 1 Oct 87 16:58:56 PDT.]
Ed asked to be reminded of the parameters regarding visiting
faculty, and I thought I'd better remind everyone.
The faculty agreed some time ago that we ought to have about a
visiting professor a year, for example, a senior person we might consider
trying to recruit. If we find a person the faculty considers suitable,
it's up to the Chairman to find the money, e.g. from the budget for
someone on unpaid leave. Shapiro visited in this way. I believe there's
no-one this year.
∂02-Oct-87 1158 @score.stanford.edu:JMC@SAIL.STANFORD.EDU visiting professors and industrial lecturers
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Oct 87 11:58:32 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Fri, 2 Oct 87 11:53:53 PDT
Received: from SAIL.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Fri 2 Oct 87 11:54:03-PDT
Date: 02 Oct 87 1153 PDT
From: John McCarthy <JMC@sail.stanford.edu>
Subject: visiting professors and industrial lecturers
To: faculty@score.stanford.edu
In my previous message I should have said that visiting professors are not
the same as industrial lecturers. The latter are one per quarter and are
from local industry. The former, in my view, should primarily be
academics and will usually be from a distance. The industry lecturers
have always been appointed for a quarter, and the it seems to me that
visiting professors should normally be here for an academic year. I have
received two nominations for the visiting professor position, but both are
from local industry - Dick Duda and Reid Smith. Is there a reason why the
visiting professor position is more desirable for us and more attractive
to the potential invitee in these cases or would industrial lecturer be
more appropriate? We usually have settled the industrial lectureship
positions in January or February with negotiations opened in late fall and
this seems to suit both us and the candidates. However, the visiting
professor positions usually have to be settled in late fall so that people
can apply for leave, etc. I think we should try for some quite prominent
visiting professors.
∂02-Oct-87 1553 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Seminars
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Oct 87 15:53:50 PDT
Date: Fri 2 Oct 87 15:50:59-PDT
From: Anil R. Gangolli <GANGOLLI@Sushi.Stanford.EDU>
Subject: Upcoming AFLB Seminars
To: aflb.all@Sushi.Stanford.EDU
Office Phone: (415) 723-3605
Message-ID: <12339367659.44.GANGOLLI@Sushi.Stanford.EDU>
Here are the abstracts for the next two AFLB talks. Also included is
an abstract for another talk of possible interest to AFLB attendees.
--anil.
THIS WEEK'S TALK:
8-October-87: Marek Karpinski (Univ. of Bonn, IBM Almaden)
The Parallel Complexity
of Perfect Matching Problems
We construct fast parallel algorithms for deciding, constructing, and
enumerating all the perfect matchings in bipartite graphs with
polynomially bounded permanents. Some implications towards the
parallel complexity of general matching and counting problems are
formulated.
***** Time and place: Thurs, October 8, 12:30pm in MJH 352 (Bldg. 460) *****
NEXT WEEK'S TALK:
15-October-87: David Johnson (AT&T Bell Labs)
Near-Optimal Solutions to
Very Large Traveling Salesman Problems
Most experimental studies of algorithms for the Travel-
ing Salesman Problem (TSP) have concentrated on relatively
small test cases, instances with 100 cities or less. In
practice, however, much larger instances are frequently
encountered, both in engineering and scientific applica-
tions. This talk begins by surveying complexity results
about the TSP and the status of algorithms for finding
optimal solutions to small instances. It then goes on to
report the results of experiments with standard TSP heuris-
tics on large instances, from 500 cities to 100,000, examin-
ing the trade-offs obtainable between running time and qual-
ity of solution. Most of the standard heuristics will be
compared, including such new approaches as ``simulated
annealing,'' but particular emphasis will be placed on the
acknowledged ``champion,'' the sophisticated Lin-Kernighan
algorithm. Using various programming tricks, we have imple-
mented a version of this heuristic for the Euclidean case
that remains feasible even for 10,000 city instances (8
hours on a minicomputer), and continues to find tours that
are within 2% of optimal. For 20,000 or more cities, we
could still obtain tours that were within 5% of optimal
using Lin-Kernighan as a subroutine in a partitioning scheme
suggested by Karp. If one is willing to settle for slightly
worse tours, an approximate version of the Christofides
heuristic seems to stay within 20% of optimal and has quite
acceptable running times even for 100,000 cities.
***** Time and place: Thurs, October 15, 12:30pm in MJH 352 (Bldg. 460) ****
ANOTHER TALK OF POSSIBLE INTEREST:
New Results on Algorithms for Sparse Polynomials
Richard Zippel
Symbolics
Friday, October 9, 11:00 a.m.
Margaret Jacks Hall (Bldg 460), Room 352
Over the past ten years significant strides have been made developing
algorithms for sparse polynomials. This work has yielded algorithms
with polynomial expected running times. The probabilistic aspect of
these algorithms comes from the need to prove certain polynomials do not
vanish. In this talk we will briefly summarize the key ideas in these
probabilistic algorithms and then present some new work which makes some
of these algorithms run in deterministic polynomial time.
-------
∂03-Oct-87 1519 @Sushi.Stanford.EDU:MAYR@Score.Stanford.EDU parallel computation seminar
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Oct 87 15:19:07 PDT
Received: from Score.Stanford.EDU by Sushi.Stanford.EDU with TCP; Sat 3 Oct 87 15:16:20-PDT
Date: Sat 3 Oct 87 15:01:16-PDT
From: Ernst W. Mayr <MAYR@Score.Stanford.EDU>
Subject: parallel computation seminar
To: su-events@Score.Stanford.EDU, aflb.all@Score.Stanford.EDU,
paco@Navajo.Stanford.EDU
Message-ID: <12339620753.12.MAYR@Score.Stanford.EDU>
The PACO (Parallel Computation) seminar will resume this coming Friday,
October 9. The seminar will take place weekly, on Friday, at 1:00pm,
in room 460-352 (building 460 aka Margaret Jacks Hall, housing the
Computer Science Department).
If you'd like to receive the seminar announcements but aren't on the
paco mailing list yet, drop me a note.
If you'd even like to give a talk, let me know the title and when you'd
like to speak.
The first speaker (Oct. 9) will be Andy Goldberg, and I'll mail title and
abstract as soon as I have it. A week later, on Oct. 16, we'll have two
paco talks, one by Serge Plotkin at 1pm, and the other by Uzi Vishkin at
2:30pm. Details when available!
-ernst
-------
∂04-Oct-87 1601 @Sushi.Stanford.EDU:DIETZ%sdr.slb.com%RELAY.CS.NET@forsythe.stanford.edu Calculating the volume of a LP-feasible region
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Oct 87 16:01:39 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Sun 4 Oct 87 15:56:55-PDT
Received: by lindy.stanford.edu; Sun, 4 Oct 87 15:56:57 PDT
Resent-From: DIETZ%sdr.slb.com%RELAY.CS.NET@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Sun, 4 Oct 87 15:56:03 PDT
Date: Fri, 2 Oct 87 15:06 EDT
From: "Paul F. Dietz" <DIETZ%sdr.slb.com@relay.cs.net>
Subject: Calculating the volume of a LP-feasible region
Message-Id: <C108.THEORYNT@ibm.com>
Resent-Date: 4 Oct 1987 18:55:44-EDT (Sunday)
Resent-Sender: THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Resent-To: aflb.tn@sushi.stanford.edu
Apparently-To: aflb.tn@sushi.stanford.edu
I'd like to know if there is a fast algorithm for calculating the
volume of a convex region in n dimensions defined by the intersection
of m half-spaces. A related problem I'd also like solved is to
generate a random point, uniformly distributed, from inside such a
convex region.
Paul F. Dietz
dietz@sdr.slb.com
∂04-Oct-87 1639 @Sushi.Stanford.EDU:ladner%june.cs.washington.edu@forsythe.stanford.edu Conference Announcement for DIAC-88
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Oct 87 16:39:33 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Sun 4 Oct 87 16:32:49-PDT
Received: by lindy.stanford.edu; Sun, 4 Oct 87 16:00:06 PDT
Resent-From: ladner%june.cs.washington.edu@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Sun, 4 Oct 87 15:59:32 PDT
Date: Fri, 2 Oct 87 17:52:33 PDT
From: ladner%june.cs.washington.edu@forsythe.stanford.edu (Richard Ladner)
Subject: Conference Announcement for DIAC-88
Message-Id: <C109.THEORYNT@ibm.com>
Resent-Date: 4 Oct 1987 18:56:54-EDT (Sunday)
Resent-Sender: THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Resent-To: aflb.tn@sushi.stanford.edu
Apparently-To: aflb.tn@sushi.stanford.edu
Call for Papers
DIRECTIONS AND IMPLICATIONS OF ADVANCED COMPUTING
DIAC-88 St. Paul, Minnesota August 21, 1988
The adoption of current computing technology, and of technologies that seem
likely to emerge in the near future, will have a significant impact on the
military, on financial affairs, on privacy and civil liberty, on the medical
and educational professions, and on commerce and business.
The aim of the symposium is to consider these influences in a social,
economic, and political context as well as a technical one. The directions
and implications of current computing technology, including artificial
intelligence and other areas, make attempts to separate science and policy
unrealistic. We therefore solicit papers that directly address the wide range
of ethical and moral questions that lie at the intersection of science and
policy.
Within this broad context, we request papers that address the following
suggested topics. The scope of the topics includes, but is not limited to,
the sub-topics listed.
RESEARCH DIRECTIONS DEFENSE APPLICATIONS
oλ+ Ethical Issues in Computing Research oλ+ AI and the Conduct of War
oλ+ Sources and Effects of Research Funding oλ+ Limits to the Automation of War
oλ+ Responsible Software Development oλ+ Automated Defense Systems
COMPUTING IN A DEMOCRATIC SOCIETY COMPUTERS IN THE PUBLIC INTEREST
oλ+ Community Access oλ+ Computing for the Handicapped
oλ+ Computerized Voting oλ+ Resource Modeling
oλ+ Civil Liberties oλ+ Arbitration and Conflict Resolu
oλ+ Risks of the New Technology oλ+ Software and the Professions
oλ+ Computing and the Future of Work oλ+ Software Safety
Submissions will be read by members of the program committee, with the
assistance of outside referees. The program committee includes Steve Berlin
(MIT), Jonathan Jacky (U. WA), Richard Ladner (U. WA), Bev Littlewood (City
U., London) Nancy Leveson (UCI), Peter Neumann (SRI), Luca Simoncini (U.Reggio
Calabria, Italy), Lucy Suchman (Xerox PARC), Terry Winograd (Stanford), and
Elaine Weyuker (NYU).
Complete papers, not exceeding 6000 words, should include an abstract, and a
heading indicating to which topic it relates. Reports on in-progress or
suggested directions for future work will be given equal consideration with
completed work. Submissions will be judged on clarity, insight, significance,
and originality. Papers (4 copies) are due by April 1, 1988. Notices of
acceptance or rejection will be mailed by June 1, 1988. Camera ready copy is
due by July 1, 1988. Send papers to Professor Nancy Leveson, ICS Department,
University of California, Irvine, Irvine, CA 92717.
Proceedings will be distributed at the symposium, and will be available during
the 1988 AAAI conference. The DIAC-87 proceedings are being published by
Ablex. Publishing the DIAC-88 proceedings is planned. The program committee
will select a set of submitted papers to be considered for publication in the
_λC_λo_λm_λm_λu_λn_λi_λc_λa_λt_λi_λo_λn_λs _λo_λf _λt_λh_λe _λA_λC_λM.
For further information contact Nancy Leveson (714-856-5517) or Doug Schuler
(206-865-3226).
Sponsored by Computer Professionals for Social Responsibility
P.O. Box 717
Palo Alto, CA 94301
∂05-Oct-87 1049 RICHARDSON@score.stanford.edu Faculty Lunch
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 5 Oct 87 10:49:08 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Mon, 5 Oct 87 10:44:26 PDT
Date: Mon 5 Oct 87 10:44:35-PDT
From: Anne Richardson <RICHARDSON@score.stanford.edu>
Subject: Faculty Lunch
To: faculty@score.stanford.edu
Message-Id: <12340098312.13.RICHARDSON@Score.Stanford.EDU>
The CSD Faculty lunch will be on MJH 146 on Tuesday, October 6 at 12:15
with Valerie Veronin to talk about the NWC process.
-------
∂05-Oct-87 1628 @score.stanford.edu:IRVINE@SUMEX-AIM.STANFORD.EDU $500,000 for research
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 5 Oct 87 16:27:58 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Mon, 5 Oct 87 16:22:39 PDT
Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Mon 5 Oct 87 16:21:39-PDT
Date: Mon, 5 Oct 87 16:17:07 PDT
From: Sue Irvine <Irvine@sumex-aim.stanford.edu>
Subject: $500,000 for research
To: faculty@score.stanford.edu
Cc: Feigenbaum@sumex-aim.stanford.edu, Irvine@sumex-aim.stanford.edu
Message-Id: <12340158849.58.IRVINE@SUMEX-AIM.STANFORD.EDU>
The NSF annually gives a prize of $500K for research to a promising young
scientist. The Alan Waterman Prize Committee has been disappointed that few
qualified COMPUTER scientists are nominated.
Please contact the following person to make nominations:
E.F. Infante, Dean
Institute of Technology
105 Walter Library
117 Pleasant Street S.E.
University of Minnesota
Minneapolis, Minnesota 55455
-------
∂05-Oct-87 1738 @score.stanford.edu:nilsson@Tenaya.Stanford.EDU $500,000 for research
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 5 Oct 87 17:38:48 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Mon, 5 Oct 87 17:35:31 PDT
Received: from Tenaya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 5 Oct 87 17:35:38-PDT
Received: by Tenaya.Stanford.EDU (3.2/SMI-3.2)
id AA04372; Mon, 5 Oct 87 17:35:23 PDT
Date: Mon, 5 Oct 87 17:35:23 PDT
From: nilsson@tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8710060035.AA04372@Tenaya.Stanford.EDU>
To: Irvine@sumex-aim.stanford.edu
Cc: faculty@score.stanford.edu, Feigenbaum@sumex-aim.stanford.edu,
Irvine@sumex-aim.stanford.edu
In-Reply-To: Sue Irvine's message of Mon, 5 Oct 87 16:17:07 PDT <12340158849.58.IRVINE@SUMEX-AIM.STANFORD.EDU>
Subject: $500,000 for research
I have some official forms for the Waterman nomination. People who would
like to make nominations can check with Anne Richardson about getting
copies of the forms. -Nils
∂06-Oct-87 1312 @Sushi.Stanford.EDU:svante%DNA.LU.Se@forsythe.stanford.edu Call for papers
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Oct 87 13:12:03 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 6 Oct 87 13:02:02-PDT
Received: by lindy.stanford.edu; Tue, 6 Oct 87 12:04:28 PDT
Resent-From: svante%DNA.LU.Se@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Tue, 6 Oct 87 12:03:49 PDT
Date: Tue, 6 Oct 87 10:12:52 +0100
From: Svante Carlsson <svante%DNA.LU.Se@forsythe.stanford.edu>
Subject: Call for papers
Message-Id: <C110.THEORYNT@ibm.com>
Resent-Date: 6 Oct 1987 15:02:14-EDT (Tuesday)
Resent-Sender: THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Resent-To: aflb.tn@sushi.stanford.edu
Apparently-To: aflb.tn@sushi.stanford.edu
Scandinavian Workshop on Algorithm Theory
(SWAT)
Halmstad, Sweden, July 5-8, 1988
The workshop is intended to be the first of a bi-annual forum for researchers
in the area of design and analysis of algorithms.
We invite submissions of papers presenting original research in areas related
to algorithm theory, including data structures, computational geometry, and
computational complexity. Contributors should send 4 copies of an extended
abstract (5-10 pages) to
Andrzej Lingas
Department of Computer Science
Linkoping University
S- 581 83 Linkoping, Sweden
by February 15, 1988. Notification of acceptance is given by April 15, 1988.
A collection of the accepted papers will be available at the workshop, and
official proceedings will be issued afterwards.
Invited Speakers: Kurt Mehlhorn (Saarbrucken)
Ian Munro (Waterloo)
Mark Overmars (Utrecht)
Derick Wood (Waterloo)
Chee Yap (New York)
Not inclusive
Organizing Committee: Bengt Aspvall (Bergen)
Svante Carlsson (Lund)
Rolf Karlsson (Linkoping)
Andrzej Lingas (Linkoping)
Further Information
The workshop will be held at Nya hotel Tylosand in Halmstad. The hotel is
located on one of the best and most well-known beaches in Sweden, and close
to many beautiful golf courses. Halmstad is on the west coast of Sweden and
easily reachable from all major Swedish cities and only three hours by train
from Copenhagen. For further information, please contact Svante Carlsson
(Dept. of Computer Science, Lund University, Box 118, S-221 00 LUND, Sweden,
tel. +46 - 46 - 108034, email: svante@dna.lu.se)
The workshop is arranged under the auspices of EATCS the week before ICALP
in Tampere, Finland.
∂07-Oct-87 0753 TOM@score.stanford.edu SCORE
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Oct 87 07:53:24 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Wed, 7 Oct 87 07:48:22 PDT
Date: Wed 7 Oct 87 07:31:33-PDT
From: Thomas Dienstbier <TOM@score.stanford.edu>
Subject: SCORE
To: csd@score.stanford.edu, staff@score.stanford.edu,
faculty@score.stanford.edu
Message-Id: <12340587460.13.TOM@Score.Stanford.EDU>
If you can read this... SCORE is running but very "FLAKY". Save your
work offten and hopefully we can get it fixed soon. So far we have a good idea
on what the problem is, but have not been able to pin it down to a failing
device.
thanks
tom←
-------
∂07-Oct-87 1152 KUDER@CSLI.Stanford.EDU SSP Phone list
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Oct 87 11:52:22 PDT
Date: Wed 7 Oct 87 11:53:23-PDT
From: Margie Kuder <KUDER@CSLI.Stanford.EDU>
Subject: SSP Phone list
To: SSP-faculty@CSLI.Stanford.EDU
Message-ID: <12340635127.43.KUDER@CSLI.Stanford.EDU>
Opps - computer error. Please change on your phone list John Etchemendy's
phone number to 3-0855 from 3-0885 and Ivan Sag's EM number to SAG@csli
instead of SAF@csli. By the way, Ivan Sag is also on leave this year.
-------
∂07-Oct-87 1331 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Polymorphism
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Oct 87 13:31:08 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Wed 7 Oct 87 13:17:55-PDT
Received: by lindy.stanford.edu; Wed, 7 Oct 87 13:18:02 PDT
Received: by Forsythe.Stanford.EDU; Wed, 7 Oct 87 13:17:20 PDT
Received: by NDSUVM1 (Mailer X1.24) id 0047; Wed, 07 Oct 87 15:11:00 CDT
Date: 7 Oct 1987 16:01:37-EDT (Wednesday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: lloyd allison <MUNNARI!MONCSKERMIT!MONCSBRUCE!LLOYD@uunet.uu.net>
Subject: Polymorphism
To: No Name <AFLB.TN@sushi.stanford.edu>
Help: Please mail me if you know how to get the newsletter 'Polymorphism'.
∂07-Oct-87 1417 HILBERT@CSLI.Stanford.EDU Agenda for Faculty Lunch
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Oct 87 14:17:12 PDT
Date: Wed 7 Oct 87 14:18:40-PDT
From: David Hilbert <HILBERT@CSLI.Stanford.EDU>
Subject: Agenda for Faculty Lunch
To: ssp-faculty@CSLI.Stanford.EDU
Message-ID: <12340661574.31.HILBERT@CSLI.Stanford.EDU>
First a reminder that the faculty lunch is Monday, Oct. 12 at 12:00.
Try to come on time to get your food before the 12:05 crunch.
Agenda
Announcements
1. Introductions: New staff and faculty.
2. Dean's request for a visionary 3 year statement of plans.
3. Microcomputer project course: how it works.
4. Overseas studies and SSP.
5. Lunch on the terrace with the students - Oct. 15.
Business Items
1. Report from Van Hinkle, student representative.
2. Report on the issue of adding a math course to the core
requirement.
See you Monday.
Dave Hilbert
Program Coordinator
-------
∂07-Oct-87 1428 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu A finite representation of rationals
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Oct 87 14:28:48 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Wed 7 Oct 87 13:29:54-PDT
Received: by lindy.stanford.edu; Wed, 7 Oct 87 13:30:06 PDT
Received: by Forsythe.Stanford.EDU; Wed, 7 Oct 87 13:29:12 PDT
Received: by NDSUVM1 (Mailer X1.24) id 0809; Wed, 07 Oct 87 15:16:29 CDT
Date: 7 Oct 1987 16:01:38-EDT (Wednesday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Peter Wayner <WAYNER%SVAX.CS.CORNELL.EDU@forsythe.stanford.edu>
Subject: A finite representation of rationals
To: No Name <AFLB.TN@sushi.stanford.edu>
Does anyone have any references on a
method of encoding all rational fractions into a finite representation of
the form:
P
- = a a a a ..... a
Q 2 3 4 5 n
where each a is an integer, 0<=a < i.
i i
with the result being
P ( a )
- = sum ( ---i-- )
Q ( i! )
Thank you:
Peter Wayner
(wayner@crnlcs.bitnet or wayner@svax.cs.cornell.edu )
∂07-Oct-87 1457 HILBERT@CSLI.Stanford.EDU Mellon fellowships
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Oct 87 14:56:58 PDT
Date: Wed 7 Oct 87 14:58:39-PDT
From: David Hilbert <HILBERT@CSLI.Stanford.EDU>
Subject: Mellon fellowships
To: ssp-faculty@CSLI.Stanford.EDU
Message-ID: <12340668852.31.HILBERT@CSLI.Stanford.EDU>
The Mellon foundations offers (generous) graduate fellowships to
seniors planning to begin graduate school in the humanities.
Candidates must be nominated by a faculty member in order to be
considered. A list of SSP seniors is at the end of this message. It
would be nice if any of our students who seemed appropriate for these
fellowships could be nominated. The deadline for nominations is Nov.
2 and student applications are due by Dec.2. If you know of any of our
seniors who is considering graduate school in a humanities discipline
(Philosophy for example) you should consider nominating him or her.
If you need any other information regarding the fellowships I have a
copy of the memo that was distributed.
Dave Hilbert
Program Coordinator
Seniors
Rick Busch
Alan Bush
David FRancis
Paul Gentry
David Goretsky
Van Henkle
Edward Katz
Robert Kylberg
Thomas Lee
Michael Short
Michael Schwe
Atticus Tyson
James White
-------
∂07-Oct-87 2329 SF@CSLI.Stanford.EDU Seminar in Logic and Foundations of Mathematics
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Oct 87 23:29:34 PDT
Date: Wed 7 Oct 87 23:32:11-PDT
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: Seminar in Logic and Foundations of Mathematics
To: logmtc@Sail.Stanford.EDU
Message-ID: <12340762340.19.SF@CSLI.Stanford.EDU>
Speaker: S. Feferman
Subject: The paper by Y. Moschovakis, "Abstract recursion as a foundation
for the theory of algorithms", Springer Lecture Notes in
Maths. v. 1104 (1984), 289-362.
Place: Stanford University, Dept. of Mathematics, Room 381-T (note
room change from previous time).
Time: Monday, Oct. 12, 4:15-5:30
-----
In this paper, Moschovakis gives an approach to gneralized recursion
theory and an intensional theory of algorithms via the theory of
inductive definitions. Some historical background and relations
to other work will be indicated. First of two talks.
-------
∂08-Oct-87 0817 TOM@score.stanford.edu SCORE
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Oct 87 08:17:18 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Thu, 8 Oct 87 08:10:52 PDT
Date: Thu 8 Oct 87 08:09:49-PDT
From: Thomas Dienstbier <TOM@score.stanford.edu>
Subject: SCORE
To: csd@score.stanford.edu, staff@score.stanford.edu,
faculty@score.stanford.edu
Message-Id: <12340856572.11.TOM@Score.Stanford.EDU>
The problem that has been a plague to SCORE has been discovered( a faulty power
supply). Probably caused from the campus power shut downs. We will
still need to take SCORE down to reconstruct it back to the original hardware
configuration. I expect this not to take more than 2 hours.
Thank you for your patience in dealing with this problem.
tom
-------
∂08-Oct-87 1324 @score.stanford.edu:LES@SAIL.Stanford.EDU CS 300 in Winter?
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Oct 87 13:24:24 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Thu, 8 Oct 87 13:19:55 PDT
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 8 Oct 87 13:19:55-PDT
Date: 08 Oct 87 1317 PDT
From: Les Earnest <LES@sail.stanford.edu>
Subject: CS 300 in Winter?
To: faculty@score.stanford.edu
The available dates for the CS 300 lecture series filled up rather quickly
this year and there are at least a couple of people who missed out.
The "final" schedule is attached.
In view of the demand, we might offer a continuation in the Winter
Quarter, but we would need about nine lectures. In order to explore this
possibility, I hereby invite offers to talk in a possible Winter series.
If there are not enough to offer the course again, we might be able to
persuade some of the currently scheduled speakers to share some of their
time.
Les Earnest
----------------------------------
Class meets on Thursdays from 4:15 to 5:30 in Room 320-334 (Geology Corner).
DATE SPEAKER TOPIC
10/1 Les Earnest Introduction to Stanford CSD
10/8 Zohar Manna Logic of Programs
10/15 David Dill Automatic Verification of Speed-independent
Circuits
10/22 Vaughan Pratt Languages for Specifying Information Systems
10/29 David Luckham Specification Languages and New
Programming Environments
11/5 David Ungar Self: a Streamlined Language for
Object-oriented Exploratory Programming
11/12 Yoav Shoham Reasoning about time, and also about space
11/19 Anoop Gupta Research in Parallel Symbolic Processing
and Computer Architectures
& Daniel Weise Automatic Synthesis of Digital Systems
11/26 [Thanksgiving]
12/3 Marty Tenenbaum AI in Manufacturing
∂08-Oct-87 1403 EMMA@CSLI.Stanford.EDU CSLIC CAlendar, Oct. 8, 3:2
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Oct 87 14:03:53 PDT
Date: Thu 8 Oct 87 12:29:55-PDT
From: Emma Pease <Emma@CSLI.Stanford.EDU>
Subject: CSLIC CAlendar, Oct. 8, 3:2
To: friends@CSLI.Stanford.EDU
Tel: (415) 723-3561
Message-ID: <12340903922.28.EMMA@CSLI.Stanford.EDU>
The CSLI mailer failed to send the the Calendar to everyone
on the mailing list so I am remailing it.
Emma
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
8 October 1987 Stanford Vol. 3, No. 2
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 8 October 1987
3:30 p.m. Tea
Ventura Hall
4:15 p.m. CSLI/Philosophy Colloquium
Philosophy Providing a Rational Basis for Morality
Bldg. 90:91A Holly Smith, Dept. of Philosophy,
University of Arizona
--------------
CSLI ACTIVITIES FOR NEXT THURSDAY, 15 October 1987
2:15 p.m. CSLI Seminar
Classroom The Acquisition of Morphology
Ventura Trailers Discussion of the debate between
Rumelhart/McClellan and Pinker/Prince
Dave Rumelhart, (der@psych.stanford.edu)
Abstract in next week's Calendar
3:30 p.m. Tea
Ventura Hall
4:15 p.m. CSLI Colloquium
Classroom A Logic for Practical Reasoning
Ventura Trailers Tim Flannagan, Logica Cambridge
Abstract below
--------------
NEXT WEEK'S COLLOQUIUM
A Logic for Practical Reasoning
Tim Flannagan, Logica Cambridge
October 15
We construct a formal logic for practical reasoning (PR) from an
analysis of Kenny's informal `logic of satisfactoriness' [K], which is
intended to preserve `satisfactoriness' in passing from premises to
conclusions just as deductive logic preserves logical truth.
Whereas Kenny's logic argues to sufficient means to ends, PR argues
both to necessary means and to sufficient means. It models intuitive
sufficiency as material implication and satisfactoriness as relative
consistency. Unlike Kenny's logic it has a precise definition of
defeasibility.
PR extends first-order logic with the following rule of inference
which we call comodus ponens. From G (understood as a goal) and C
implies G, infer C, provided that C and G are jointly consistent
relative to X (the nonlogical axioms). PR has the following
properties:
1. If A is a logical consequence of X, then it is derivable in PR from
X but the converse is false.
2. If A is derivable from X, then it is consistent with X.
3. The separate derivability of two sentences from a set X does not
imply that their conjunction is derivable. It is thus possible for
A and `not A' to be derivable without this resulting in a
contradiction.
4. PR is a defeasible logic and hence strongly nonmonotonic.
--------------
SITUATION SEMANTICS WORKING GROUP
Tuesdays 10:00-11:45, Ventura Hall
(First meeting: Tuesday, 13 October)
Contacts
Craige Roberts (Croberts@csli.stanford.edu)
Stanley Peters (Peters@csli.stanford.edu)
Members of this group will explore Situation Semantics from a
linguistic point of view. To this end we hope to first consolidate
our understanding of the theory in its current state of development,
and then use this perspective to explore some current issues in
linguistic semantics.
In keeping with the trend of current research in semantics, we
assume that three general criteria for an adequate semantic theory
are:
(i) partiality in modeling,
(ii) adequate tools for talking about context-dependence, and
(iii) ability to assign sufficiently fine-grained meanings.
We plan to entertain more specific questions and criteria as
refinements of (i), (ii), and (iii), and explore how Situation
Semantics addresses these questions and fulfills these criteria, and
how it compares in these respects with other current theories.
In order to establish a basis for discussion, at our first session
Stanley Peters will give an overview of the version of Situation
Semantics developed in Barwise and Etchemendy's THE LIAR. It might be
useful for those planning to attend to have a look at that work
beforehand. (Note: For those interested in Situation Semantics,
attendance at John Etchemendy's seminar on THE LIAR would be helpful,
but is not necessary for participation in this group.)
After some further preliminaries, there are a number of particular
issues which we hope to explore. To begin, we will focus on
conditionals and modality, linguistic phenomena which require a
semantic theory based on situations (and/or partial worlds). These
phenomena also introduce questions of context-dependence and
fine-grainedness. We will compare work on these issues within
Situation Semantics to other contemporary theories such as that of
Kratzer (in her paper on the ``Lumps of Thought''), Data Semantics
(Landman and Veltman), and to Muyskens' work on partiality in
possible-worlds semantics.
At the first meetings, other possible topics will be suggested. In
addition, participants are urged to propose topics and lead sessions
themselves in accordance with their own research interests.
Although we will focus on linguistic issues, all members of the
CSLI community, students, and visitors are invited to attend and
participate fully.
-------
∂08-Oct-87 1537 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu New Address
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Oct 87 15:37:40 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Thu 8 Oct 87 15:19:50-PDT
Received: by lindy.stanford.edu; Thu, 8 Oct 87 15:19:58 PDT
Received: by Forsythe.Stanford.EDU; Thu, 8 Oct 87 15:18:04 PDT
Received: by NDSUVM1 (Mailer X1.24) id 9061; Thu, 08 Oct 87 17:04:11 CDT
Date: 8 Oct 1987 13:42:01-EDT (Thursday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Ralf Hofestaedt <UNI128%DBNRHRZI@forsythe.stanford.edu>
Subject: New Address
To: No Name <AFLB.TN@sushi.stanford.edu>
TO WHOM IT MAY CONCERN
NEW ADDRESS:
DEPT. COMP. S.C..
ROEMERSTR. 164
D5300 BONN 1
BITNET: UNI128 at DBNRHRZ1
∂08-Oct-87 1559 RICHARDSON@score.stanford.edu Janos Komlos
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Oct 87 15:59:38 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Thu, 8 Oct 87 15:54:59 PDT
Date: Thu 8 Oct 87 15:54:41-PDT
From: Anne Richardson <RICHARDSON@score.stanford.edu>
Subject: Janos Komlos
To: faculty@score.stanford.edu
Message-Id: <12340941198.15.RICHARDSON@Score.Stanford.EDU>
I am happy to be able to report that on October 7, 1987 the School of
Engineering Executive Committee unanimously approved the appointment
of Prof. Janos Komlos to the position of Professor (one-half billeted
in CSD). Sol Feferman of the Math Dept. and I will let Komlos know of
this immediately (I think he is now visiting in Hungary) and extend
him Stanford's formal offer (conditioned, of course, on Provostial and
Board approval). -Nils
-------
∂08-Oct-87 1647 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: A call for references on finite representation of rationals.
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Oct 87 16:47:29 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Thu 8 Oct 87 16:36:13-PDT
Received: by lindy.stanford.edu; Thu, 8 Oct 87 16:36:25 PDT
Received: by Forsythe.Stanford.EDU; Thu, 8 Oct 87 16:35:33 PDT
Received: by NDSUVM1 (Mailer X1.24) id 0564; Thu, 08 Oct 87 18:24:16 CDT
Date: 8 Oct 1987 13:42:02-EDT (Thursday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Gerald A. Edgar" <CBOSGD!OSU-CIS!TUT!EDGAR%UCBVAX.BERKELEY.EDU@forsythe.stanford.edu>
Subject: Re: A call for references on finite representation of rationals.
To: No Name <AFLB.TN@sushi.stanford.edu>
In article <1706@svax.cs.cornell.edu> wayner@svax.cs.cornell.edu (Peter Wayner)
>
>Does anyone have any references on a
>method of encoding all rational fractions into a finite representation of
>the form:
>
> P
> - = a a a a ..... a
> Q 1 2 3 4 5 n
>
>
> where each a is an integer, 0<=a < i.
> i i
>with the result being
>
>P ( a )
>- = sum ( ---i-- )
>Q ( (i+1)! )
>
>
>
Begin with:
G. Cantor, Zeitschrift fur Mathematik und Physik 14 (1869) 121--128.
More modern ref:
D. Knuth, The Art of Computer Programming, vol. 2, sec. 4.1.
--
Gerald A. Edgar
Department of Mathematics
The Ohio State University
Columbus, OH 43210
∂08-Oct-87 1711 @score.stanford.edu:nilsson@Tenaya.Stanford.EDU NSF S&T Centers
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Oct 87 17:11:34 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Thu, 8 Oct 87 17:06:19 PDT
Received: from Tenaya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 8 Oct 87 17:06:13-PDT
Received: by Tenaya.Stanford.EDU (3.2/SMI-3.2)
id AA07196; Thu, 8 Oct 87 16:23:00 PDT
Date: Thu, 8 Oct 87 16:23:00 PDT
From: nilsson@tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8710082323.AA07196@Tenaya.Stanford.EDU>
To: faculty@score.Stanford.EDU
Cc: levinthal@sierra.Stanford.EDU
Subject: NSF S&T Centers
I sent around an announcement from NSF about their new Science and
Technology Centers. Notice of intent to propose is due on Nov 15, and
proposals are due on Jan. 15. I have suggested to the "theory group"
(aka "foundations") that perhaps a Stanford Center for the Foundations
of CS might be appropriate. Perhaps others of you might be thinking of
"Centers." Please remember, if you are thinking about a proposal, to
inform Elliott Levinthal (SOE Assoc. Dean for Research) asap so he can
alert people to possible overlaps with other Stanford proposals. (Anne
Richardson has a copy of the NSF announcement for any of you who did
not receive a copy.) -Nils
∂09-Oct-87 1314 RICHARDSON@score.stanford.edu Janos Komlos
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Oct 87 13:14:15 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Fri, 9 Oct 87 13:08:20 PDT
Date: Fri 9 Oct 87 13:08:07-PDT
From: Anne Richardson <RICHARDSON@score.stanford.edu>
Subject: Janos Komlos
To: faculty@score.stanford.edu
Message-Id: <12341173020.17.RICHARDSON@Score.Stanford.EDU>
I am happy to be able to report that on October 7, 1987 the School of
Engineering Executive Committee unanimously approved the appointment
of Prof. Janos Komlos to the position of Professor (one-half billeted
in CSD). Sol Feferman of the Math Dept. and I will let Komlos know of
this immediately (I think he is now visiting in Hungary) and extend
him Stanford's formal offer (conditioned, of course, on Provostial and
Board approval). -Nils
-------
∂09-Oct-87 1350 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB talks
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Oct 87 13:50:42 PDT
Date: Fri 9 Oct 87 13:29:19-PDT
From: Anil R. Gangolli <GANGOLLI@Sushi.Stanford.EDU>
Subject: Upcoming AFLB talks
To: aflb.all@Sushi.Stanford.EDU
Office Phone: (415) 723-3605
Message-ID: <12341176879.28.GANGOLLI@Sushi.Stanford.EDU>
THIS WEEK'S TALK:
15-October-87: David Johnson (AT&T Bell Labs)
Near-Optimal Solutions to
Very Large Traveling Salesman Problems
Most experimental studies of algorithms for the Travel-
ing Salesman Problem (TSP) have concentrated on relatively
small test cases, instances with 100 cities or less. In
practice, however, much larger instances are frequently
encountered, both in engineering and scientific applica-
tions. This talk begins by surveying complexity results
about the TSP and the status of algorithms for finding
optimal solutions to small instances. It then goes on to
report the results of experiments with standard TSP heuris-
tics on large instances, from 500 cities to 100,000, examin-
ing the trade-offs obtainable between running time and qual-
ity of solution. Most of the standard heuristics will be
compared, including such new approaches as ``simulated
annealing,'' but particular emphasis will be placed on the
acknowledged ``champion,'' the sophisticated Lin-Kernighan
algorithm. Using various programming tricks, we have imple-
mented a version of this heuristic for the Euclidean case
that remains feasible even for 10,000 city instances (8
hours on a minicomputer), and continues to find tours that
are within 2% of optimal. For 20,000 or more cities, we
could still obtain tours that were within 5% of optimal
using Lin-Kernighan as a subroutine in a partitioning scheme
suggested by Karp. If one is willing to settle for slightly
worse tours, an approximate version of the Christofides
heuristic seems to stay within 20% of optimal and has quite
acceptable running times even for 100,000 cities.
***** Time and place: Thurs, October 15, 12:30pm in MJH 352 (Bldg. 460) *****
NEXT WEEK'S TALK:
22-October-87: Thane Plambeck (Stanford)
The Complexity of Nim
and Taking and Breaking Games
We study algorithms for a broad class of impartial two-player perfect
information games known as ``taking and breaking games.'' Included in
this class are the games of Nim, Kayles, Dawson's chess, Treblecross,
and all finite octal and tetral games. No knowledge of these games
will be assumed and the relevant theory will be developed from first
principles. Our results include NC algorithms for an infinite
subclass of taking and breaking games, and a P-completeness result for
the recognition of winning positions of these games when the rules of
the game are specified as part of the input.
***** Time and place: Thurs, October 22, 12:30pm in MJH 352 (Bldg. 460) *****
-------
∂09-Oct-87 1406 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: A finite representation of rationals
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Oct 87 14:06:31 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Fri 9 Oct 87 13:46:57-PDT
Received: by lindy.stanford.edu; Fri, 9 Oct 87 13:42:07 PDT
Received: by Forsythe.Stanford.EDU; Fri, 9 Oct 87 13:41:15 PDT
Received: by NDSUVM1 (Mailer X1.24) id 7983; Fri, 09 Oct 87 15:31:31 CDT
Date: 9 Oct 1987 16:23:02-EDT (Friday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Marty Cohen <MCOHEN@nrtc.northrop.com>
Subject: Re: A finite representation of rationals
To: No Name <AFLB.TN@sushi.stanford.edu>
Here is my solution to ...
> Does anyone have any references on a
> method of encoding all rational fractions into a finite representation of
> the form:
>
> P
> - = a a a a ..... a
> Q 2 3 4 5 n
>
>
> where each a is an integer, 0<=a < i.
> i i
> with the result being
>
> P ( a )
> - = sum ( ---i-- )
> Q ( i! )
>
>
>
> Thank you:
>
> Peter Wayner
>
> (wayner@crnlcs.bitnet or wayner@svax.cs.cornell.edu )
It is just a conversion to algorithmic form of Cantor's theorem that such
a representation actually exists.
Input: A fraction p/q, 0 < p/q < 1
Output: The set of a and the number of a .
n n
Notation: int(...)=integer part of ..., a|b means a divides b,
(a, b) = greatest common divisor of a and b,
oo = infinity, "<>" means "not equal".
Algorithm: Let n=1, r =p/q.
1
Repeat until tired: n=n+1, a = int(n!r ), r = r -(a /n!).
n n-1 n n-1 n
All that needs to be added are proofs of convergence, termination,
and uniqueness.
1. r < 1/n! (easily proved by induction starting with r < 1).
n 1
2. a <= n-1 (follows from (1) and n!r < n!/(n-1)! = n).
n n-1
3. Let r = p /q , (p , q ) = 1. If n <= m and q|m! then q |m!.
n n n n n n
True for n=1 since q =q.
1
If true for n-1, where n<m, then
m!r = (m!/q )p = (m!/q )p - (m!/n!)a
n n n n-1 n-1 n
= an integer since q |m! and n!|m!.
n-1
Since (p , q ) = 1, q |m!.
n n n
4. If q|m! then r =0 (this proves termination at a ).
m m
Suppose r > 0. Then p >= 1 so that r = p /q >= 1/m!.
m m m m m
But this contradicts result (1) for n=m.
5. The representation is unique:
n m
if sum a /k! = sum b /k! where n, m >1 and 0 <= a , b < k
k=2 k k=2 k k k
then n=m and a = b for all k.
k k
oo
Proof: Follows from sum (k-1)/k! = 1/(n-1)! (telescoping sum)
k=n
where n is the smallest k such that a <> b .
k k
(If a >b , the rest of the b are not large enough to
n n k
make the 2 sums equal.)
Looking this over, I notice that the result and method of proof
applies to any representation of the form
m
sum a /D , where D = d d ...d with each d being an integer >= 2
k=1 k k k 1 2 k i
and each a satisfies a < d .
k k k
The case of all d being equal to an integer d gives the standard
i
base d representation, and d =i gives the representation here.
i
(Just start the algorithm with at n=0 with r = p/q - we started
0
at n=1 since a always = 0 (because a < d =1)).
1 1 1
Thanks for an entertaining few hours,
Marty Cohen
mcohen@nrtc.northrop.com
∂09-Oct-87 1744 @score.stanford.edu:nilsson@Tenaya.Stanford.EDU [CLOUTIER@Sierra.Stanford.EDU: Senate Proposal Regarding NSF Funds]
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Oct 87 17:44:33 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Fri, 9 Oct 87 17:38:25 PDT
Received: from Tenaya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 9 Oct 87 13:52:07-PDT
Received: by Tenaya.Stanford.EDU (3.2/SMI-3.2)
id AA08112; Fri, 9 Oct 87 13:52:19 PDT
Date: Fri, 9 Oct 87 13:52:19 PDT
From: nilsson@tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8710092052.AA08112@Tenaya.Stanford.EDU>
To: faculty@score.Stanford.EDU
Subject: [CLOUTIER@Sierra.Stanford.EDU: Senate Proposal Regarding NSF Funds]
Return-Path: <@Score.Stanford.EDU:CLOUTIER@Sierra.Stanford.EDU>
Date: Fri 9 Oct 87 13:13:01-PDT
From: Mary Cloutier <CLOUTIER@Sierra.Stanford.EDU>
Subject: Senate Proposal Regarding NSF Funds
To: xcomx@Sierra.Stanford.EDU
Cc: cloutier@Sierra.Stanford.EDU
The American Education Association has notified the Dean's office of a
move in the Senate next week to take $l00 million out of the NSF budget to
support veteran's programs. These programs do deserve support but the
objection is being raised as to whether the funds should be taken out
of the NSF budget. Senator Allan Cranston would like to hear the views of as
many of you as possible before this goes on the Senate floor.
Could you alert your faculty to this move and those that are moved to
respond can do so by sending a telegram to Senator Allan Cranston, SH-ll2,
Hart Building, washington, D.C. 205l0 or phone John Steinberg, a staff
member in Cranston's Washington office, at (202) 224-6202.
Mary Cloutier
-------
∂09-Oct-87 1800 @score.stanford.edu:lma@Anna.stanford.edu PAVG Speaker Series
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Oct 87 18:00:23 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Fri, 9 Oct 87 17:58:14 PDT
Received: from Anna by SCORE.STANFORD.EDU with TCP; Fri 9 Oct 87 10:35:25-PDT
Received: by Anna with Sendmail; Fri, 9 Oct 87 10:36:25 pdt
Date: Fri, 9 Oct 87 10:36:25 pdt
From: Larry M. Augustin <lma@anna.stanford.edu>
To: faculty@score.Stanford.EDU, students@score.Stanford.EDU
Subject: PAVG Speaker Series
Program Analysis and Verification Group
Fall Speaker Series
The Program Analysis and Verification Group (PAVG) in the Computer
Systems Lab at Stanford University is proud to announce its Fall
Speaker Series. Sessions will be held on Monday afternoons in ERL and
set in a highly informal and interactive atmosphere. The informal
atmosphere is designed to allow speakers who are too busy to give
prepared formal talks the opportunity to give unprepared informal
presentations of of up-to-the-minute research. We don't want or
expect the speakers to have to take time out of their busy schedules
to specially prepare for the talks. Subjects will include, but are
not limited to: formal verification, hardware design/description
languages, parallel programming, and parallel simulation. The first
session will be held on Monday, October 12 at 2:30 in ERL 401 and will
feature Jim Horning of DEC Western Research Labs on the Larch
specification language. Anyone interested in attending or being added
to the announcement mailing list should contact lma@anna.stanford.edu.
Larry M. Augustin ERL 414
lma@anna.stanford.edu Computer Systems Lab
augustin@sierra.stanford.edu Stanford University
(415) 723-9285 Stanford, CA 94305
∂09-Oct-87 1802 RICHARDSON@score.stanford.edu NSF S&T Centers
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Oct 87 18:02:13 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Fri, 9 Oct 87 17:59:44 PDT
Date: Fri 9 Oct 87 13:09:35-PDT
From: Anne Richardson <RICHARDSON@score.stanford.edu>
Subject: NSF S&T Centers
To: faculty@score.stanford.edu
Cc: levinthal@sierra.stanford.edu
Message-Id: <12341173286.17.RICHARDSON@Score.Stanford.EDU>
I sent around an announcement from NSF about their new Science and
Technology Centers. Notice of intent to propose is due on Nov 15, and
proposals are due on Jan. 15. I have suggested to the "theory group"
(aka "foundations") that perhaps a Stanford Center for the Foundations
of CS might be appropriate. Perhaps others of you might be thinking of
"Centers." Please remember, if you are thinking about a proposal, to
inform Elliott Levinthal (SOE Assoc. Dean for Research) asap so he can
alert people to possible overlaps with other Stanford proposals. (Anne
Richardson has a copy of the NSF announcement for any of you who did
not receive a copy.) -Nils
-------
∂10-Oct-87 1256 BSCOTT@score.stanford.edu Unrestricted Accounts
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 10 Oct 87 12:56:38 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Sat, 10 Oct 87 12:54:54 PDT
Date: Sat 10 Oct 87 12:54:41-PDT
From: Betty Scott <BSCOTT@score.stanford.edu>
Subject: Unrestricted Accounts
To: Faculty@score.stanford.edu
Cc: BScott@score.stanford.edu
Message-Id: <12341432718.12.BSCOTT@Score.Stanford.EDU>
If you have any kind of unrestricted account in CS, I will be sending you
a copy of the 8/31/87 Fund Statement showing any account activity (receipts,
expenditures, etc.) in the next few days. I have high-lighted the balance
available as of 9/1/87. Let me know if you have any questions about the
statements.
Betty
-------
∂12-Oct-87 0144 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #72
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Oct 87 01:44:09 PDT
Date: Sun 11 Oct 1987 09:45-PDT
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #72
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Monday, 12 Oct 1987 Volume 5 : Issue 72
Today's Topics:
Query - Algebraic simplification & Prolog Machines,
Implementation - Asthetics & findall/3
----------------------------------------------------------------------
Date: 2 Oct 87 10:07:36 GMT
From: Eddy Szulcm <cvax!dlt1!szulc@uunet.uu.net>
Subject: Algebraic simplification
I'm looking for an algorythm, preferably in Prolog, for simplifying
an algebraic expression. My first attempts can handle expressions of
the form 2+a+3 => 5+a, but gets lost with 2+a+3+b+4. I know that I
could flatten the trees, sort them and then re-construct them, but I
need something that works for all sorts of operators and that can be
defined by simple rules.
------------------------------
Date: 6 Oct 87 14:48:00 GMT
From: iuvax!silver!bondc@rutgers.edu
Subject: Re: Algebraic simplification algorythm
A-L-G-O-R-I-T-H-M
------------------------------
Date: 6 Oct 87 02:53:14 GMT
From:Mark Thomsen <trwrb!trwspf!thomsen@ucbvax.Berkeley.EDU>
Subject: Looking For Prolog Machines
Help me on a search if you can.
In our laboratory we have considerable interest in running things
quickly, and have developed and bought a number of fast non-general
processors for implementing certain functions or languages quickly.
We are preparing to work with Prolog for some embedded expert and
deductive processing functions, and I am not familiar with what can be
purchased to run Prolog programs fast. If left in our current state
of ignorance, we will probably buy Modula-Prolog, put it on MC68020's
(where we have an excellent Modula-2 compiler), and do our own speed
enhancements.
What is out there that runs Prolog fast? I have heard a little about
the ICOT effort on PSI, but have not technical article or description.
I have also seen articles in the past on extracting concurrency,
Concurrent Prolog, and the like -- are there concurrent Prolog
machines?
I would like any references or descriptions on Prolog machines that
you guys know of. I will submit a summary of received data in a few
weeks. Thanks!
-- Mark R. Thomsen
------------------------------
Date: 9 Oct 87 13:35:11
Gcvax!dartvax!tedc@ucbvax.Berkeley.EDU (Ted Cooley)
Subject: Re: Looking For Prolog Machines
There may also be the Xenologic Processor. This machine is to be
an add-on to the SUN workstations. Claims of up to 300Klips are claimed.
Xenologic is in Berkeley, CA.
------------------------------
Date: 9 Oct 87 13:38:05 GMT
From: mit-vax!jouvelot@eddie.mit.edu (Pierre Jouvelot)
Subject: Re: Looking For Prolog Machines
This followup is from a friend (Akihiko Konagaya)
-- Pierre
It is true that PSI is rather slower. But it's not unfair to compare a
toy hardware and a workstation with a full programming environment.
Processor performance is considerablly diminished by various traps,
which are required for the environment.
As for performance, new PSI achieves 200-250 KLIPS. This is fairly
good because the performance of most useful application programs are
determined by the performance of built-in predicates but "append
program". Futhermore, we know that 2 Mega LIPS is not so difficult,
if we develop a custom Prolog chip with 20 MHz.
The fastest Prolog machine currently available would be CHI-II
developed at NEC. It achieved 500KLIPS (See Habata etal, "Co-operative
High Performance Sequential Inference Machine" in ICCD '87 New York
for the details). The full programming environment that includes
multi-window interface, mutiple process environment as well as
ordinary programming tools such as an optimizing compiler, an
interpreter with incremental compiler, would be available at the end
of 1987.
CHI-II provides an extended prolog, named SUPLOG, which is powerful
enough to implement whole system programs on CHI-II. It supports not
only whole prolog language features but also supports multiple name
space, interprocess communication facilities and various data types
(characters, arrays, streams etc). The subset of SUPLOG will be
available on a UNIX workstation soon.
The prototype CHI, oridinally named HPM, achieved 280 KLIPS. Its
architecture and an programming environment are reported in:
Nakazaki etal, "Design of a high-speed prolog machine HPM",
in Proc. of Computer Architecture, 1985.
Konagaya etal, "A Co-Operative Programming Environment for a Back
-End Type Sequential Inference Machine CHI", in Proc. of
Parallel Algorithms and Architecture, 1987, Akademie-Verlag Berlin.
Copies are available until Jan. 1988 in the following address:
Akihiko Konagaya
MIT Laboratory for Computer Science,
545 Technology Square, room 252,
Cambridge, MA 02139
In case of after Jan. 1988, try to access:
Akihiko Konagaya
Computer System Laboratory,
C&C Systems Laboratories,
NEC Coporation, 1-1 Miyazaki, 4-chome, Miyamae,
Kawasaki, Kanagawa, 213 Japan
------------------------------
Date: Thu, 1 Oct 87 19:46:40 PDT
From: quintus!cresswell!ok@Sun.COM (Richard A. O'Keefe)
Subject: findall/3
This is really very embarrassing. Lagache's library is such a
wonderful source of examples that I keep writing about it. I am so
very sorry about this. Here is a public-spirited sort of fellow, no
doubt expecting nothing but thanks, and here I am saying all sorts
of critical things about his code. But what a wonderful source of
examples! There are so many things to criticise, and everyone who
gets the Prolog Digest will know what I am talking about.
This time, it isn't really his fault. Lagache's version of
findall/3 has a serious bug, but this bug was present in the code
in Clocksin & Mellish which he copied, and in his copy he has at
least tried to reduce the chance of the bug biting.
Here is the code from Clocksin & Mellish:
findall(Template, Generator, List) :-
asserta(found(mark)),
call(Generator),
asserta(found(Template)),
fail.
findall(Template, Generator, List) :-
collect_found([], Matches),
!,
List = Matches.
collect_found(Matches0, Matches) :-
getnext(Match),
!,
collect_found([Match|Matches0], Matches).
collect_found(Matches, Matches).
getnext(Match) :-
retract(found(Match)),
!,
Match \== mark.
The bug, of course, is that Template musn't ever be bound to 'mark'.
The query
?- findall(X, member(X,[tom,dick,harry]), L).
works, but the query
?- findall(X, member(X,[matthew,mark,luke,john]), L).
doesn't work at all.
Lagache has improved this code by using a much less plausible atom.
But what a pity that he didn't take the trouble to eliminate the bug
entirely.
As a matter of fact, it isn't Clocksin & Mellish's fault either,
really. The bug is present in DEC-10 Prolog. Which is why I care
about the bug. You see, I was bitten by it. In all innocence, I
wrote a DEC-10 Prolog program which did something perfectly
sensible, but it broke mysteriously. I just could not figure out
what was going wrong. Fernando Pereira took one look at it, and saw
the problem at once. The moral of the story is that there is no atom
so bizarre that a programmer may not encounter it quite innocently.
How can we avoid the bug? By systematic design in the first place.
There are two conditions we want to represent on the stack:
- there is a marker here
- there is a solution X here
How do you do that? Always, Always, Always, the right way to represent
cases in Prolog is to have a different constructor function for each.
(You may have to deal with "anything else" cases in the input of your
programs, but you shouldn't design your own data structures that way.)
These two cases map DIRECTLY onto
- marker
- solution(X)
Another point, which isn't exactly a bug, is that it is rather
regrettable to take such an obviously useful predicate name as
found/1 away from the user. We don't need to do that. (It is
far easier for a user to avoid predicate names with spaces in them
than to avoid an atom he isn't supposed to know about.)
Accordingly, we can code findall/3 like this:
findall(Template, Generator, List) :-
asserta('findall stack'(marker)),
call(Generator),
asserta('findall stack'(solution(Template))),
fail.
findall(Template, Generator, List) :-
'findall collect'([], List).
'findall collect'(List0, List) :-
retract('findall stack'(Item)),
!,
'findall collect'(Item, List0, List).
'findall collect'(marker, List, List).
'findall collect'(solution(X), List0, List) :-
'findall collect'([X|List0], List).
This has one cut, not three, and no instances of \==, and not only
is it less ugly, it doesn't suffer from the bug. In fact, if you
define another library predicate:
retract_first(Clause) :-
retract(Clause),
!.
which is generally useful, we can see that the one surviving cut
hasn't really got anything to do with findall/3 as such.
Much may be forgiven the pioneers of a field. I do not fault
the designers of DEC-10 Prolog for this bug. (They went on to
produce Quintus Prolog, which naturally has NOT got this bug.)
However, it has always been a bug, not a feature.
+-------------------+
|READ THIS PARAGRAPH|
|EVEN IF NAUGHT ELSE|
+-------------------+
What is really important here is this systematic approach to
designing data structures. If you want to represent situations
s1 with data d11,...,d1k1
...
sn with data dn1,...,dnkn
use terms
s1(D11,...,D1k1)
...
sn(Dn1,...,Dnkn)
to do it, so that you can tell later on what you meant by looking
at the principal functor. If there is a most common case, it is
very tempting to ex-Lisp programmers to make that the "else" case
of an if-then-else (or a 'caseq') and avoid the "inefficiency" of
putting a wrapper around that case. DON'T DO IT. It will actually
make your programs LESS efficient (because there will be a 'variable'
case in your predicates, which will need cuts in all the preceding
clauses, which take time to execute, and you'll probably get
temporary choice-points you can do without).
Lagache's code for findall/3 is a straightforward improvement
of Clocksin & Mellish's. But his documentation is his own. And
that is very strange. Here is that documentation, retyped rather
sloppily so that you won't have to look it up:
findall(Variable_atom, Predicate, Binding_list)
generates a list of all values of Variable_atom
that satisfy Predicate.
findall is the classic predicate for collecting all
the values of Variable_atom that are true of Predicate.
The values are returned on list Binding_list.
Both Binding_list and Variable_atom should be unbounded.
Prolog code is based on Clocksin and Mellish p 162.
The variable Variable_atom must be some atom in the
Predicate call. For example, to build up the list of
integers between 1 and 10 the following call will
do the trick:
findall(X, between(1,10,X), Numberlist)
(a) What is a 'variable atom'?
The first argument is usually a variable. But it may be
ANY term, and it is very useful to pass a skeletal term
(a compound term with unbound arguments). It even makes
sense to pass a constant, sometimes.
The argument need not be an atom "in the Predicate call".
Presumably he means "the Generator must bind the Template
to an atom". In fact, in his own example, the Template
gets bound to integers, not atoms.
It is true that findall/3 doesn't make much sense if the
Generator doesn't bind the Template to a ground term.
But if you want to call
findall(Name, (member(X,[fred,jim]),name(X,Name)), Names)
go right ahead. It will work.
(b) The second argument is a Goal, not a Predicate.
Anything that is acceptable to call/1 is acceptable here,
which is to say that anything which is acceptable as the
body of a clause is acceptable.
(c) Is 1 really "true of" between(1,10,X) ?
(d) Presumably he means "unbound", not "unbounded". In fact,
there isn't the slightest need for the third argument to
be unbound. This is one of the few predicates where
Lagache warns you about the need for output arguments to
be unbound, and the irony is that findall/3 is steadfast!
Suppose you wonder whether there are at least two proofs
for a goal G. It makes perfect sense to call
findall(*, G, [*,*|_]).
Go ahead and do it. findall/3 won't mind. It'll even work!
Lagache goes on to say in his documentation:
LIMITATIONS: None.
There are certainly fewer limitations than he thought.
BUGS: No Known Bugs.
Well, now it's known.
To summarise this section, there is a serious problem with the
code that Lagache copied, but that isn't his fault.
Lagache also offers a predicate countmatch/2. There are
two things that
countmatch(Goal, Count)
might have meant:
how many SOLUTIONS are there?
how many PROOFS could Prolog find?
His documentation makes it perfectly clear that he means the
latter. There is also a sum_match/3.
Let's look at his code. (By the way, I can't thole run-on
words. The underscore is there. Let's use it. The Melbourne
Mob prefer capitalisation, as in countMatch. See Arthur Sale's
article in SP&E, or any good book on general programming style.
"ADA in Practice" has some good tips.)
count_match(Generator, _) :-
asserta(current_count(0)),
call(Generator),
increment_current_count,
fail.
count_match(_, Count) :-
current_count(Count),
retract(current_count(Count)).
increment_current_count :-
current_count(M),
N is M+1,
retract(current_count(M)),
asserta(current_count(N)),
!.
Is there anything wrong with this? Yes, it is neither
steadfast nor backwards correct. If I ask whether a goal G
has exactly 2 proofs by calling
count_match(G, 2)
and it turns out to have 3, what happens? The call
current_count(2) in the second clause of count_match/2 fails,
and the counter is never retracted. Is that so bad? Yes,
because if this call to count_match/2 is dynamically nested
inside another call to count_match/2 (and why should it not
be?) the counter call will start using the inner call's
counter. OH DEAR.
Using the predicate retract_first/1 defined earlier, we
can code count_match/2 thus:
count_match(Generator, _) :-
asserta('count match'(0)),
call(Generator),
retract_first('count match'(Sum0)),
Sum1 is Sum0+1,
asserta('count match'(Sum1)),
fail.
count_match(_, Count) :-
retract_first('count match'(Total)),
Count = Total.
To the best of my belief, this is a correct implementation of
the operation that Lagache documented.
His sum_match/3 has a very serious bug: he uses assertz/1
rather than asserta/1, which means that calls to sum_match/3
cannot be nested. Since he got count_match/2 very nearly right,
this is probably a slip rather than a systematic error. There
is a detail which is good: he checks that the number found by
the generator IS a number before trying to add it to the Sum.
But sum_match/3 has the same problem as count_match/2:
zero_sum(Template, Generator) :-
sum_match(Template, Generator, 0)
will do terrible things if the sum is NOT 0. Again, recoding as
sum_match(Template, Generator, _) :-
asserta('sum match'(0)),
call(Generator),
integer(Template),
retract_first('sum match'(Sum0)),
Sum1 is Sum0+Template,
asserta('sum match'(Sum1)),
fail.
sum_match(_, _, Sum) :-
retract_first('sum match'(Total)),
Sum = Total.
fixes the bug, and we can see by inspection that count_match(G, C)
is equivalent to sum_match(1, G, C).
However, neither count_match/2 nor sum_match/3 is what we
usually want.
The basic problem is the distinction between SOLUTIONS and PROOFS.
We typically want solutions, and if we want to build logical relations
solutions are what we need, but what Prolog finds is proofs. Normally,
we couldn't care less how many proofs there are.
Let's look at a very simple case. We have a relation
phone(Office, PhoneNumber)
and we'd like to be able to count the number of phones in an office.
Modulo the justified criticisms of setof/3, the right way to do this
is
phone_count(Office, Count) :-
setof(Phone, phone(Office,Phone), Phones),
length(Phones, Count).
Given a particular phone, we can ask about how many phones it has.
Given a count, we can ask which offices have that many phones.
Or, if phone/2 can be enumerated, Prolog can enumerate pairs of
Offices and Counts.
Now suppose phone/2 is defined like this:
phone(Office, Number) :-
occupant(Office, Person),
extension(Person, Number).
Fine. But if an office has two occupants,
count_match(phone(Office,_), Count)
will return 2 when it should have returned 1.
This is not a criticism of Lagache or his library. He never
claimed that count_match/2 would be useful in a case like this.
setof/3 and bagof/3 have a property which some people find
strange (who have never fully realised the difficulties implied
by the connection between setof(X, G, []) and ~G), namely that
they will never return an empty list. There are useful hybrids
between {setof,bagof}/3 and findall/3:
set_of_all(Template, Generator, Set) :-
'sound query'(Generator, Template, Goal),
findall(Template, Goal, List),
sort(List, Set).
bag_of_all(Template, Generator, Bag) :-
'sound query'(Generator, Template, Goal),
findall(Template, Goal, Bag).
'sound query'(Exvar↑Generator, Template, Goal) :- !,
'sound query'(Generator, Exvar↑Template, Goal).
'sound query'(Goal, Template, Goal) :-
numbervars(Template, 0, N1),
numbervars(Goal, N1, N2),
N2 > N1,
!,
/* report the error and only then */
fail.
'sound query'(Goal, _, Goal).
This checks that there are no variables in the Generator
which are not captured by the Template or existential quantifiers.
In that case, and ONLY in that case, it would be sound for
the routines to return an empty list of solutions.
phone_count(Office, Count) :-
set_of_all(Phone, phone(Office,Phone), Phones),
length(Phones, Count).
will give the correct results, provided that Office is instantiated,
and if Office is not ground at the time of all, it will report an
error. If you want to know how many phones are associated with
offices,
set_of_all(P, Office↑phone(Office,P), Phones)
will give you the set (list in standard order with no duplicates)
of such phones.
It is very hard to find examples where count_match/3 or
sum_match/3 would be useful. I have generally found it to be the
case that I wanted some other information about the results as
well. I would be interested to see examples where some more
general operation would not be more useful.
By the way, the Quintus library contains a predicate
aggregate/3, so that to find the mean area of the offices in
each department one could write
mean_office_area(Dept, MeanArea) :-
aggregate(sum(A)/sum(1),
Office↑(dept_office(Dept,Office), area(Office,A)),
TotalArea/Count),
MeanArea is TotalArea/Count.
This will of course enumerate departments with their mean areas
as well as finding the mean area of a given department. It is
very easy to build such a predicate on top of setof/3, and for
operations like finding the average, minimum, or maximum,
refusing to yield an empty list is just what the doctor ordered.
It would be interesting to discuss what the aggregate/3 operation
should look like: the present version is satisfactory but there
is more that it could do.
------------------------------
End of PROLOG Digest
********************
∂12-Oct-87 0755 RICHARDSON@score.stanford.edu CSD Lunch
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Oct 87 07:55:35 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Mon, 12 Oct 87 07:53:19 PDT
Date: Mon 12 Oct 87 07:53:04-PDT
From: Anne Richardson <RICHARDSON@score.stanford.edu>
Subject: CSD Lunch
To: faculty@score.stanford.edu
Message-Id: <12341902097.14.RICHARDSON@Score.Stanford.EDU>
The CSD Faculty Lunch on Tuesday, October 13 at 12:15 will take place at
the Knowledge Systems Lab conference room with Ed Feigenbaum and Elliott
Levinthal discussing "DARPA" and "Manufacturing".
-------
∂12-Oct-87 0855 BARWISE@CSLI.Stanford.EDU Reminder
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Oct 87 08:55:38 PDT
Date: Mon 12 Oct 87 08:55:24-PDT
From: Jon Barwise <BARWISE@CSLI.Stanford.EDU>
Subject: Reminder
To: ssp-faculty@CSLI.Stanford.EDU
Message-ID: <12341913446.26.BARWISE@CSLI.Stanford.EDU>
The fall lunch and faculty meeting is today, at noon, in the faculty
club. Hope to see you there.
-------
∂12-Oct-87 0902 RICHARDSON@score.stanford.edu CSD Faculty Lunch
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Oct 87 09:02:06 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Mon, 12 Oct 87 08:59:42 PDT
Date: Mon 12 Oct 87 08:59:26-PDT
From: Anne Richardson <RICHARDSON@score.stanford.edu>
Subject: CSD Faculty Lunch
To: faculty@score.stanford.edu
Message-Id: <12341914179.14.RICHARDSON@Score.Stanford.EDU>
Additional info on the lunch on Tuesday, October 13: The Knowledge Systems
Lab conference room is located at 701 Welch, Bldg. A.
-------
∂12-Oct-87 1251 @score.stanford.edu:FEIGENBAUM@SUMEX-AIM.STANFORD.EDU Re: CSD Faculty Lunch
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Oct 87 12:51:34 PDT
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Mon, 12 Oct 87 12:49:45 PDT
Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Mon 12 Oct 87 12:49:29-PDT
Date: Mon, 12 Oct 87 12:51:24 PDT
From: Edward Feigenbaum <FEIGENBAUM@sumex-aim.stanford.edu>
Subject: Re: CSD Faculty Lunch
To: RICHARDSON@score.stanford.edu, faculty@score.stanford.edu
In-Reply-To: <12341914179.14.RICHARDSON@Score.Stanford.EDU>
Message-Id: <12341956409.79.FEIGENBAUM@SUMEX-AIM.STANFORD.EDU>
More information: if you're driving, park anywhere in slots labeled
"H&W". Walk down the stairs from ground level, between the buildings labeled
"A" and "C". The conference room is on the lowest level, on the "A" side.
Ed
-------
∂13-Oct-87 0948 BARWISE@CSLI.Stanford.EDU thanks
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 Oct 87 09:48:03 PDT
Date: Tue 13 Oct 87 09:47:28-PDT
From: Jon Barwise <BARWISE@CSLI.Stanford.EDU>
Subject: thanks
To: ssp-faculty@CSLI.Stanford.EDU
Message-ID: <12342185069.26.BARWISE@CSLI.Stanford.EDU>
I want to thank all of you for coming to lunch, those who were able to
make it. I thought it was very useful.
Those of you who have further comments about the student drive to
initiate a Co-termi maters program in SSP could send your comments to
this list, or straight to Van Hinkle, j.jvlh@lear.
Thanks again. See at the lunch with students on Thursday.
Jon
-------
∂13-Oct-87 1121 TOM@score.stanford.edu INTERLEAF Publishing Demo
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 Oct 87 11:21:51 PDT
Received: from Score.Stanford.EDU ([36.8.0.46]) by labrea.stanford.edu with TCP; Tue, 13 Oct 87 11:14:31 PDT
Date: Tue 13 Oct 87 11:13:09-PDT
From: Thomas Dienstbier <TOM@score.stanford.edu>
Subject: INTERLEAF Publishing Demo
To: csd@score.stanford.edu, staff@score.stanford.edu,
faculty@score.stanford.edu
Cc: alpert@score.stanford.edu
Message-Id: <12342200667.28.TOM@Score.Stanford.EDU>
Amy Schwartz, of INTERLEAF, will be visiting our department to demonstrate
the latest "University Publisher" software release. We currently have this
software installed on Jeeves(CSDCF Sun Fileserver). Amy will be here on
Wednesday, October 21, at 1:30 and until the enthusiasm runs out.
INTERLEAF is basically a what-you-see-is-what-you-get screen(sun workstation)
editor.
Please respond to Jack Alpert/alpert@score if you plan on attending so
we can plan on room size for the demo. Room will probably be 040.
thanks
tom
-------
∂13-Oct-87 1500 RICHARDSON@Score.Stanford.EDU Manufacturing
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 Oct 87 15:00:05 PDT
Date: Tue 13 Oct 87 14:57:09-PDT
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: Manufacturing
To: faculty@Score.Stanford.EDU
Message-ID: <12342241444.26.RICHARDSON@Score.Stanford.EDU>
Copies of the viewgraphs regarding "NSF Research Programs Concerned With
Manufacturing" mentioned by Elliott Levinthal today at the faculty lunch
are in my office. Those wishing copies, please send me a net message
requesting same.
-Anne
-------
∂14-Oct-87 0211 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #73
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 14 Oct 87 02:11:16 PDT
Date: Tue 13 Oct 1987 09:29-PDT
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #73
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Wednesday, 14 Oct 1987 Volume 5 : Issue 73
Today's Topics:
Announcement - Call For Papers,
Implementation - Persimmons
----------------------------------------------------------------------
Date: Fri, 9 Oct 87 0:07:32 EDT
From: Ken Bowen <kabowen@logiclab.cis.syr.edu>
Subject: Digest Submission: Call for Papers
CALL FOR PAPERS
ASSOCIATION FOR LOGIC PROGRAMMING
Fifth International Logic Programming Conference
Fifth Symposium on Logic Programming
15-19 August 1988 -- Seattle, Washington
The Association for Logic Programming is sponsoring the first joint
meeting of the two principal Logic Programming conferences. Previous meetings
of the International Conference have taken place in Marseilles, Stockholm,
London, and Melbourne. Previous meetings of the Symposium have taken place
in Atlantic City, Boston, Salt Lake City, and San Francisco.
Authors are invited to submit papers on all aspects of Logic Programming,
including, but not restricted to:
+ Applications
+ Role in Artificial Intelligence
+ Deductive Databases
+ Relations to other computational paradigms
+ Language issues
+ Methodology
+ Implementations on sequential and parallel architectures
+ Theory
Of special interest are applications that exploit the unique character of
logic programming.
PAPERS DUE: 1 February 1988.
============================
Short papers are limited to five double-spaced 10-point pages;
Long papers are limited to twelve double-spaced 10-point pages.
Notification of Acceptance: 9 May 1988.
Camera-Ready Copy Due: 10 June, 1988.
Send five (5) copies of submitted manuscripts to the Program Chairman:
Robert A. Kowalski, LP88
Department of Computing
Imperial College
180 Queen's Gate,
London SW7 2BZ
ENGLAND
For other information contact the Conference Chairman:
Kenneth A. Bowen, LP88
Logic Programming Research Group
School of Computer and Information Science
313 Link Hall
Syracuse University
Syracuse, NY 13210
USA
Authors are also invited to submit proposals for TUTORIALS, both advanced
and introductory. Tutorial sessions may be half or full-day, and will be
conducted on a schedule throughout the week. Tutorial proposals should
include (1) a statement of the proposed topic area, (2) an outline of the
tutorial, (3) relevant bibliography, and (4) proposer's curriculum vita.
Proposals for ADVANCED TUTORIALS are especially encouraged.
Send three (3) copies of tutorial proposals to the Tutorial Chairman:
Veronica Dahl
Department of Computing
Simon Fraser University
Burnaby, B.C.
CANADA
-------------------
Date: Thu, 1 Oct 87 17:16:54 PDT
From: quintus!cresswell!ok@Sun.COM (Richard A. O'Keefe)
Subject: Persimmons
Eduoard Lagache has replied to the criticisms of his library. I
think it is worth replying to his reply, because there are some
important issues involved.
I was violently criticised here at Quintus for my first, message
on the subject. I should make it plain that my opinions are my own,
that I send messages reflecting my own opinions rather than any
official Quintus position (there isn't any such animal) or even any
general consensus among Quintus staff (people at Quintus had the
chance to read these messages only when they came back through the
Prolog Digest). My message was denounced at Quintus as "appallingly
arrogant". Three particular points that were raised were
- my characterisation of Lagache's library as "regrettable",
- my criticism of his sending an unstable version of an intrinsically
inefficient sorting routine as "perverse", and
- my claim that "a competent Prolog programmer who is concerned
with efficiency" would avoid univ (=..) except in dialects where
it was superfluous (LM Prolog, for example).
Well, yes, I should apologise for using intemperate
languauge, and I do.
I should also make it clear that while I am strongly
critical of Lagache's LIBRARY, I am not at all critical of
LAGACHE. Someone who goes to the trouble to write, DOCUMENT,
and distribute a library of any sort deserves praise. What is
regrettable about Lagache's library is that the quality of his
code is in such contrast to the quality of his character.
I should also confess that some of the errors in Lagache's
code are to be found in some old code of mine: if you look at
the public-domain file FLAT.PL you will see that the "predicates"
it defines are no more steadfast than his. (After explaining how
it should all work, I took a look at the old file to check that
it did work that way. And of course it didn't.) But if you
have been following the Prolog Digest since say 1983, you will
recall that my postings of code have tended to say "please tell
me about bugs", not "NO KNOWN BUGS".
Having said that writing, documenting, and distributing a
library is a praiseworthy act, let me point out some of the
obligations that it carries with it.
Lagache says:
"I am not a PROLOG guru, and never claimed that I was."
I'm afraid this simply is not true. To shower your code on people
who never asked for it is implicitly to say "you OUGHT to be using
this code, or at the very least you OUGHT to read and consider it
before rejecting it". To publish a book on a subject is to make
an implicit claim to your readers that you are an expert on the
subject whose opinions are worth reading. To publish source code
for a programming library is to implicitly tell your readers that
this is good code that they ought to use and/or IMITATE. If you
are not an expert, by what right do you thrust your code on our
attention?
These implicit claims can be over-ridden by explicit counter-
claims. And, readers being what they are, the counter-claims
have to be repeated in every file. (Did you ever take that
programming aptitude test which had you doing all sorts of absurd
things, and then the final instruction was "do none of the above?")
The reason that I reacted so immediately and with such vehemence
is that I was seriously worried that if immediate counter-measures
were not taken, innocent readers of the Digest would be deceived by
a general silence into imagining that Lagache's code was a model
worthy of imitation. But it is not only bad, it is systematically bad.
Since I knew of Lagache's code, and understood in what ways it was
bad, and thought I had the ability to explain the ways in which it was
bad and how to do better, it seemed to me that I had a plain duty to
the Prolog community to do so.
Let me make this clear: I surmise that Lagache's basic problem
is that he has simply never been taught how to write Prolog. There
are a lot of very bad books out there, nearly all of them, in fact.
To be fair to Lagache, some of the books he is likely to have had
access to present worse code than his. Most people, trying to write
Prolog by "the light of nature" and with the aid of such books, do a
rather bad job of it. I'll repeat a point I made in an earlier
message: it looks to me as though Lagache has got his code right
with respect to every criterion he could think of, and I'm sure that
he carefully tested his code. The trouble is that he didn't know
enough of the important criteria.
Lagache speaks of "nit-pickers". He presumably means Lee
Naish, Stan Shebs, and me. He speaks of "nit-picking". Well, I
for one was not nit-picking. If it were only matters of style,
such as the use of [list|notation] or cons.notation or even if
it were only a matter of :- fail clauses, I would have remained
silent. There is something more serious at issue:
many of Lagache's predicates are just plain INCORRECT.
The fundamental problem is that Lagache is writing Lisp in Prolog.
Many things that LOOK like stylistic issues are in fact symptoms of
the same problem. Lagache thinks that when Lee Naish and I complain
about :- !, fail clauses, we are nit-picking. Wrong. Those clauses
are not neutral in their effect: they actually introduce errors.
Lagache seems to think that
merge([],[],[]). % 'lagache'
merge([],List2,List2):- !, fail.
merge(List1,[],List1):- !, fail.
merge([Head1|Tail1],[Head2|Tail2],[Head1,Head2|R]):-
merge(Tail1,Tail2,R), !.
is easier to read than
merge([], [], []). % 'pure'
merge(Head1.Tail1, Head2.Tail2, Head1.Head2.R) :-
merge(Tail1,Tail2,R).
He explicitly condemns the latter as "cryptic", and "terse",
and suggests that people who write "terse" code should "go back
and take a course in structured Pascal".
Let's keep the falsely-so-called "algebraic" languages out of
the discussion. What would this look like in a good modern
application language, of the type of ML? (I can't remember the
actual ML syntax, so handwave a bit.)
merge nil nil = nil.
merge nil H2.T2 = failwith "wrong length".
merge H1.T1 nil = failwith "wrong length".
merge H1.T1 H2.T2 = H1.H2.(merge T1 T2).
As a matter of fact, this is ill-typed unless the two arguments
have the same type of elements. Some compilers, having worked
out that the type is
merge : list(Alpha) x list(Alpha) -> list(Alpha)
then check that each combination of the constructors must have an
explicit equation. Since list(Alpha) has constructors
nil : -> list(Alpha)
. : Alpha x list(Alpha) -> list(Alpha)
there must be four cases, one for each pair of constructors. This
leads to the code I wrote. But ML has an exception handling facility,
triggered by the 'failwith' construct.
Lacking a comparable generally accepted construct in Prolog,
let's define a fail_with/1 of our own. If something is actually
an error, your code should not just quietly fail, but should
print an error message. After that, all you can do is 'fail'
or 'abort'. You should seriously consider 'abort'.
fail_with(Message) :-
format(user_error, '~N! Error: ~w~n', [Message]),
fail.
A faithful translation of the ML style into Prolog would then be
merge([], [], []).
merge([], [_|_], _) :- fail_with('merge/3: wrong length').
merge([_,_], [], _) :- fail_with('merge/3: wrong length').
merge([H1|T1], [H2|T2], [H1,H2|T3]) :-
merge(T1, T2, T3).
PROVIDED that this was documented as ONLY being usable to
compute the third argument from the first two, this would be tolerable.
Mind you, I find it extremely odd that
merge([], [a], X)
would be reported as an error, but that
merge([], a, X)
would NOT be reported. What is so special about wrong length that
it is the only error that deserves reporting? Another problem is
that merge/3 is not the best name for this operation. merge/3
is more commonly used for merging two ORDERED lists (ordered set
union, as it were). Lagache's merge/3 is neither this nor the
stream merge used in committed choice languages. What this predicate
actually does is to INTERLEAVE its first two arguments. Why not call
it interleave/3?
Let's suppose that we don't really regard it as a serious error
to provide lists of the wrong length. Let's suppose that we just
want to list all the combinations of constructors as a general
discipline, and want to make it explicit that certain combinations
are NOT in the relation. Then the code to use is
merge([], [], []). % 'defensible'
merge([], [_|_], _) :- fail.
merge([_,_], [], _) :- fail.
merge([H1|T1], [H2|T2], [H1,H2|T3]) :-
merge(T1, T2, T3).
I don't really like it, but it IS a defensible coding style.
Coding in this style can indeed help you eliminate "missing
clause" cases, and it is indeed arguable that it makes life
easier for the human reader.
But it is NOT what Lagache wrote! His code was
merge([], [], []). % 'lagache'
merge([], [_|_], _) :- !, fail.
merge([_,_], [], _) :- !, fail.
merge([H1|T1], [H2|T2], [H1,H2|T3]) :-
merge(T1, T2, T3),
!.
And this is NOT easier to read than the 'pure' version.
The reader first has to ask himself: "why is there a cut at the end
of the last clause?" It turns out that there is no good reason,
but it takes a lot of effort to work that out. The reader then
has to ask himself: "why are there cuts in the preceding two
clauses?" And again, it turns out that there is no good reason.
In fact, those cuts stop you using this predicate to decompose
a given last argument, which is a perfectly sensible thing to want
to do.
So yes, ":- fail" clauses are always redundant, and that is all
they are, and Lagache could have dismissed complaints about them as
nit-picking. But ":- !, fail" clauses are NOT redundant! They
actually change what the code MEANS. It can be quite hard to work
out what the effect is, and it seems clear that Lagache has not
done this, otherwise he wouldn't think that they are redundant.
The only material difference between the 'defensible' version
(which is presumably what Lagache intended) and the 'pure' version
is the genuinely redundant :- fail clauses. Can we find an objective
reason for preferring one or the other? There is an initial
difficulty, because the two styles are trying to help the reader
answer two different questions:
(1) The 'defensible' version helps you answer the question:
for which arguments is the query SENSIBLE?
(2) The 'pure' version helps you answer the question:
for which arguments is the query TRUE?
Speaking for myself, I always read code expecting to found out
the conditions under which the predicate is true (or, if it is a
command), the conditions under which the command will take effect.
So I am asking the second question. When I want to know the answer
to the first question, I look at the comments. I find it very
confusing to read my way through a clause, only to find at the
last minute "GOTCHA! DON'T use this clause!". For merge/3, there
are only two ways that the predicate can be true. Having four
clauses obscures this.
But what about someone who is interested in the other question?
Well, is there any need to answer the question in the CODE? Would
not the following text answer everyone's questions:
% merge(L1, L2, Merge)
% is true when all three arguments are lists, and
% L1 = [X1,...,Xn] for some n,
% L2 = [Y1,...,Yn] for the same n, and
% Merge = [X1,Y1,X2,Y2,...,Xn,Yn].
% This predicate can be used to solve for any two
% of the arguments given the other one, but at
% least one of the arguments should be proper.
merge([], [], []). % 'defensible'
merge([H1|T1], [H2|T2], [H1,H2|T3]) :-
merge(T1, T2, T3).
To get this thing in perspective, let's consider another
example. One of my earlier messages included a predicate
sort_aux([], [], [], [], []).
sort_aux([K|Ks], [V|Vs], [K-V|Ps], [W|Ws], [_-W|Qs]) :-
sort_aux(Ks, Vs, Ps, Ws, Qs).
This has five arguments. 2**5 = 32. Would Lagache really want
me to write 32 clauses, only two of which provide useful information?
You might object that I was actually supplying only two inputs, so
I would only need four cases. But there is NOTHING in this predicate
to say which arguments are inputs and which arguments are outputs.
Let me give you another example. Imagine that we have a
data type 'country' with 100 country names as nullary constructor
functions, and a data type 'city' with 300 names as nullary
constructor functions, and that we want to represent the relation
between countries and capitals. In a functional language, we would
write
capital(belgium) = brussels.
capital(britain) = london.
...
capital(bolivia) = sucre. % I asked 'chat' for this one
is_capital_of(brussels) = belgium.
is_capital_of(london) = britain.
is_capital_of(sucre) = bolivia.
is_capital_of(berkeley) = failwith 'is_capital_of'.
...
is_capital_of(new_york) = failwith 'is_capital_of'.
Writing down 200 equations that say so-and-so is not the capital of
any country is rather tedious, but at least there are only 200 such
equations in this example.
Now suppose that we code this in Prolog. It is perfectly
plausible that we will get questions like 'is it true that new_york
is the capital of the usa?'. In the 'pure' style, we just list the
100 clauses which are true:
capital(belgium, brussels).
capital(britain, london).
...
capital(bolivia, sucre).
But in the other style, we have to list all the sensible combinations
which are false, as well. And that is 29,900 of them!
So now we see in full clarity the hidden assumption behind the
style Lagache favours:
there is always a SMALL number of arguments
which are always inputs, and they are made from
a SMALL set of constructor functions, and the
other arguments are always outputs.
As Lee Naish pointed out, there is nothing in the 'pure' version
of merge/3 to encourage you to regard any of the arguments as special:
the 'pure' version makes a simple logical statement which a Prolog
system can use to solve for any two of the arguments given the others.
The redundant clauses in the 'defensible' version actually serve to
mislead the reader: they suggest that the first two arguments are
very different from the last one. That is, they put BLINKERS over
the reader's eyes.
So we see that the practice of introducing ":- fail" clauses
(1) is laudible practice in functional programming languages
(2) is part of a "functional" mind-set which discourages effective
use of Prolog
(3) cannot be consistently carried out for predicates which have
many inputs, or inputs with many cases.
We simply CANNOT follow this practice in many cases. Suppose we
SOMETIMES follow the practice. Different programmers will be patient
to different degrees. So a reader looking at a peice of code which
does not use :-fail clauses has to ask himself "is this significant,
or did the programmer just get tired?". Bah!
Since we cannot carry the practice out all the time, it is better
never to start. People who publish source code have no right to
squander their reader's time like this.
Apart from this inevitable "global" inconsistency in the :-fail
style, does it tend to have good or bad effects in other ways?
Well, we've already seen that there is a temptation to use :-!,fail
instead, which is almost always wrong. Can we find any other
problems in Lagache's code that can be attributed to this practice?
Yes we can.
nthcdr(Tail, 0, Tail).
nthcdr([], _, []) :- !, fail.
nthcdr([_|Tail], Index, Result) :-
Next is Index-1,
nthcdr(Tail, Next, Result).
THIS WORKS (at least, it is naive correct). But notice what it says!
The first two clauses manage to claim that nthcdr([],0,[]) is both
true (first clause) and false (second clause). This is "logic"
programming? He has also managed to obscure the fact that this is a
perfectly ordinary induction on the second argument.
We see, therefore, that there is some evidence that the :-fail
style may confuse the writer as well as the reader. There are
objective reasons to prefer the 'pure' style.
Another reason to prefer the 'pure' style is that it naturally
arises in a disciplined approach to designing logic programs. For
example, it is often easiest to design a predicate by induction on
the OUTPUT. You want to know "what inputs could give rise to this
output", and listing all sorts of inputs that COULDN'T really does
not help.
What about quicksort and univ? It has been pointed out to me
that the DEC-10 Prolog manual, the C Prolog manual, and so on, do
not say anything about the efficiency or otherwise of 'univ'.
The answer is that I expect "a competent Prolog programmer who is
concerned about efficency" to do what I did:
- THINK about it. Something which forces you to construct a
list which you don't want should arouse suspicion.
- MEASURE it. Your intuition about Prolog efficiency is not
to be trusted. My intuition about Prolog efficiency is not
to be trusted. The way to find out what is the efficient
way to code something is to code as many variants as you
have wit and energy for and MEASURE them.
If anybody other than my critic interpreted my statements about
"univ" as an attack on Lagache, stand corrected. I never supposed
that efficiency was Lagache's first concern in his library, nor
that it should have been. The statement was intended as a piece
of advice directed to everybody.
The other objection to my initial comments on Lagache's library
was my strong criticism of his recommending quicksort. (And let me
remind you that including something in a library is a "structural"
recommendation to use it, unless there is an explicit counter-claim.)
My critic reckoned that Lagache was not setting himself up as an
expert on sorting methods in Prolog or any other language, and should
not be criticised for not having informed himself of the problems of
quicksort and the virtues of merge sort.
My counter-claim is that publishing library source code IS a
structural claim of expertise, and that someone who recommends a
particular sorting routine to a large group of people has an
obligation to inform himself of at least the elementary facts
about sorting routines. It is not necessary to have writting
"The Art of Programming, Volume 3: Sorting and Searching". But
one ought to have READ it.
What is the advantage of quick-sort over merge-sort? It can
be implemented very efficiently >>in languages with cheap
updateable arrays<<. The point is that the partitioning phase
can be done in-place. This means that the only extra storage
that quick-sort needs is space for a very small stack (a fixed
table of 2*N words will let you sort arrays of up to 2**N words).
This advantage does not exist in pure functional languages,
and it does not exist in Prolog. Even with SICStus Prolog's
backtrackable setarg/3, this advantage does not exist. Lagache's
code for quick-sort does not sort the list in place: it constructs
lots and lots of new lists. As it should. That's how you do it
in Prolog.
Is there any other advantage of quick-sort over merge-sort?
Well, look at the name. Surely it must be faster. WRONG. Even
in languages like Fortran, Pascal, or ADA, quick-sort is not the
method of choice. There have indeed been studies which have gone
as far as counting individual instructions, and every one of them
has concluded that quick-sort is a very fast method indeed. But
then, every one that I have read was actually considering the
very special case of sorting an array of numbers, where comparing
two numbers was a single machine instruction. In that case, OF
COURSE quick-sort is going to look good. It does very little
book-keeping. But if you want to sort an array of integers,
there are methods with O(N) expected cost, so you would be silly
to use quick-sort with its O(N.lgN) expected cost. You can
recode k-bit floating-point numbers as k-bit integers so as to
preserve order (the PDP-10 actually used the same instructions
to compare integers and floats) so the same methods can be used
to sort arrays of k-bit floats. As soon as comparison becomes
at all costly (such as when you are sorting strings, or when you
are calling a user-supplied comparison routine), quick-sort turns
out to be less efficient than merge-sort even in conventional
languages, because it does more comparisons.
I have to admit that most people probably don't know that,
and that it would not be fair for me to expect Lagache to know
it. But it IS fair to expect someone who has heard of quick-
sort to know that its worst-case behaviour is O(N↑2), and that
the version which Lagache distributed has the worst case when
the list is already sorted, and it is also fair to expect
someone to know that merge sort has O(N.lgN) worst case time as
well as O(N.lgN) average time, and that the constant factors
aren't all that different either. You don't actually have to
understand Knuth Vol 3, you just have to look at the
conclusions.
Another of quicksort's defects is that it suffers badly when
the input contains lots of duplicates. Handling them in place
is rather tricky, though methods have been published. The good
news is that handling duplicates in the Prolog version is trivial,
and that doing so restores stability. But that does nothing about
the worst-case behaviour.
It was wrong of me to describe Lagache's distribution of
an unstable quadratic-worst-case algorithm when a stable n-log-n
algorithm has been in use for years as "perverse". I would only
have been entitled to say that if I had known that he knew what
he was doing. I didn't (and don't) know that. But I do know
that he ought to have known what he was doing, and that in his
documentation, he claims ("the execution time is quite reasonable")
that he does know what he was doing.
A comment something like this
"This is the best sorting method I know of in Prolog.
If anyone knows of a better one, please tell me."
would have served as a counter-claim to the structual claim of
expertise.
Someone who offers his code for general use must expect
criticism of it. You have no right to say BOTH "here, you ought
to use this" AND "no nit-picking". I have no right to expect
the code I sent to the library in '83 and '84 to be immune from
criticism. I wish it HAD been criticised, there were several
things wrong with it. (Every flaw that I learn of is fixed in
the Quintus version of the library. The more criticism of my
code the better, say I.) If you offer people medlars, you must
expect persimmons back.
------------------------------
End of PROLOG Digest
********************
∂14-Oct-87 0816 BARWISE@CSLI.Stanford.EDU please remind your students
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 14 Oct 87 08:06:51 PDT
Date: Wed 14 Oct 87 08:06:12-PDT
From: Jon Barwise <BARWISE@CSLI.Stanford.EDU>
Subject: please remind your students
To: ssp-faculty@CSLI.Stanford.EDU
Message-ID: <12342428778.12.BARWISE@CSLI.Stanford.EDU>
Please mention the lunch for ssp majors and faculty in those classes
where you think it appropriate. The lunch is tomorrow, in back of
building 60. (If people ask whether prospective majors are welcome,
say, "Sure". I just hope we don't get 100 people.)
-------
∂14-Oct-87 0841 BARWISE@CSLI.Stanford.EDU Faculty Development Lab
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 14 Oct 87 08:41:28 PDT
Date: Wed 14 Oct 87 08:40:29-PDT
From: Jon Barwise <BARWISE@CSLI.Stanford.EDU>
Subject: Faculty Development Lab
To: ssp-faculty@CSLI.Stanford.EDU
Message-ID: <12342435017.12.BARWISE@CSLI.Stanford.EDU>
In case you did not see an invitation, the new Faculty Development Lab
will be formally opened on Thursday, Oct 22, at 4:30. There will be a
reception and some demos. It is on the ground floor (i.e. basement)
of Sweet Hall.
At this reception, there will be a discussion of the Courseware
Authoring Tools (CAT) project. This project is designing very
high level tools for the creation of certain kinds of courseware.
While the lab could be quite useful to us in developing SSP
courseware, I doubt that the CAT project will be. It would be useful
if you could go and give your reactions to the project, and how it
will or will not serve your needs. There is an effort underway to get
the provost to make money available for courseware development along
the old FAD lines. To push for this, we need to make it clear that
the sorts of things done by CAT are not going to meet our needs, if
this is the case.
It seems to me that SSP faculty (including consulting faculty!) are
prime candidates to develop exciting and innovative courseware. We
need to make ourselves felt as a presence. So I hope you will come
and talk to the staff at the reception about your needs and ideas.
Jon
-------
∂14-Oct-87 0926 @CSLI.Stanford.EDU:nilsson@Tenaya.Stanford.EDU Faculty Development Lab
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 14 Oct 87 09:26:00 PDT
Received: from Tenaya.Stanford.EDU by CSLI.Stanford.EDU with TCP; Wed 14 Oct 87 09:24:48-PDT
Received: by Tenaya.Stanford.EDU (3.2/SMI-3.2)
id AA01689; Wed, 14 Oct 87 09:24:14 PDT
Date: Wed, 14 Oct 87 09:24:14 PDT
From: nilsson@Tenaya.Stanford.EDU (Nils Nilsson)
Message-Id: <8710141624.AA01689@Tenaya.Stanford.EDU>
To: BARWISE@CSLI.Stanford.EDU
Cc: ssp-faculty@CSLI.Stanford.EDU, nilsson
In-Reply-To: Jon Barwise's message of Wed 14 Oct 87 08:40:29-PDT <12342435017.12.BARWISE@CSLI.Stanford.EDU>
Subject: Faculty Development Lab
Jon and SSP faculty:
In my role as chair of the academic computing and info systems faculty
senate committee, I'm quite interested in how the various programs like
CAT are perceived by the faculty. Are they really helping us? Can they
be improved. I would be most interested in SSP faculty perceptions on this
subject. Also, anyone with suggestions about how the new Information
Resources organization (including lots and the CAT people) can be more
helpful to faculty (and students) wanting to use computers would be quite
welcome to come to one of our C-ACIS meetings. -Nils
∂14-Oct-87 1016 RICHARDSON@Score.Stanford.EDU NSF Proposal
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 14 Oct 87 10:16:01 PDT
Date: Wed 14 Oct 87 09:53:57-PDT
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: NSF Proposal
To: faculty@Score.Stanford.EDU
Message-ID: <12342448392.18.RICHARDSON@Score.Stanford.EDU>
I have an NSF Proposal announcement in my office for those interested
as follows:
This announcement describes the Undergraduate Faculty Enhancement Program,
which makes grants for Undergraduate Faculty Seminars and Conferences.
These provide opportunities for groups of faculty to learn about new
techniques and new developments in their fields.
-------
∂14-Oct-87 1219 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com PLANLUNCH NEXT MONDAY: Ramin Zabih, Stanford
Received: from WARBUCKS.AI.SRI.COM by SAIL.STANFORD.EDU with TCP; 14 Oct 87 12:19:12 PDT
Received: from venice by WARBUCKS.AI.SRI.COM via SMTP with TCP; Wed,
14 Oct 87 11:52:54-PDT
Received: by venice (3.2/4.16) id AA07312 for
planlunch@warbucks.ai.sri.com; Wed, 14 Oct 87 11:54:41 PDT
Date: Wed, 14 Oct 87 11:54:41 PDT
From: Amy Lansky <lansky@venice.ai.sri.com>
Message-Id: <8710141854.AA07312@venice>
To: planlunch@warbucks.ai.sri.com
Subject: PLANLUNCH NEXT MONDAY: Ramin Zabih, Stanford
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
DEPENDENCY-DIRECTED BACKTRACKING IN NON-DETERMINISTIC LISP
Ramin Zabih (RDZ@SUSHI.STANFORD.EDU)
Computer Science Department
Stanford University
11:00 AM, MONDAY, October 19
SRI International, Building E, Room EJ228
Dependency-directed backtracking is a strategy for solving
generate-and-test search problems. Pure Lisp extended with McCarthy's
non-deterministic operator AMB is an elegant language for expressing
such problems. I will describe how to automatically provide
dependency-directed backtracking in SCHEMER, a non-deterministic Lisp
dialect.
It is also possible for SCHEMER to automatically provide other search
strategies than dependency-directed backtracking. In fact, SCHEMER
can support a large class of solution methods. I will show that
SCHEMER programs can make use of any algorithm for determining the
satisfiability of a propositional formula in Conjunctive Normal Form.
This is joint work with David McAllester.
∂14-Oct-87 1847 EMMA@CSLI.Stanford.EDU CSLI Calendar, Oct. 15, 3:3
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 14 Oct 87 18:47:12 PDT
Date: Wed 14 Oct 87 17:42:31-PDT
From: Emma Pease <Emma@CSLI.Stanford.EDU>
Subject: CSLI Calendar, Oct. 15, 3:3
To: friends@CSLI.Stanford.EDU
Tel: (415) 723-3561
Message-ID: <12342533691.27.EMMA@CSLI.Stanford.EDU>
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
15 October 1987 Stanford Vol. 3, No. 3
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 15 October 1987
2:15 p.m. CSLI Seminar
Classroom The Acquisition of Morphology
Ventura Trailers Discussion of the debate between
Rumelhart/McClelland and Pinker/Prince
Dave Rumelhart, (der@psych.stanford.edu)
Abstract below
3:30 p.m. Tea
Ventura Hall
4:15 p.m. CSLI Colloquium
Classroom A Logic for Practical Reasoning
Ventura Trailers Tim Flannagan, Logica Cambridge
Abstract in last week's Calendar
--------------
CSLI ACTIVITIES FOR NEXT THURSDAY, 22 October 1987
12 noon TINLunch
Ventura Hall Reading: "On Language and Connectionism:
Conference Room Analysis of a Parallel Distributed Processing
Model of Language Acquisition"
by Steven Pinker and Alan Prince
Discussion led by Dave Rumelhart
(der@psych.stanford.edu)
This TINLunch is a follow up of the seminar
that will have been given on 15 October. Please
see the abstract for it below.
2:15 p.m. CSLI Seminar
Room G-19 External Language and Internal Representation
Redwood Hall Pat Hayes (Hayes.pa@xerox.com)
Abstract below
3:30 p.m. Tea
Ventura Hall
--------------
THIS WEEK'S CSLI SEMINAR
The Acquisition of Morphology
Discussion of the debate between
Rumelhart/McClelland and Pinker/Prince
Dave Rumelhart
(der@psych.stanford.edu)
October 15
A couple of years ago Jay McClelland and I developed a connectionist
model of the process of over-regularization in the acquisition of past
tense in English. We were surprised to find how well the model
accounted for the pattern of such errors children actually make.
Recently a number of authors who are associated with rather different
accounts of these results have challenged the adequacy of our model.
The most massive of these challenges has come from a large paper (150
pages) by Steve Pinker and Alan Prince. This paper is to be published
in the journal COGNITION. Pinker and Prince challenge our work on
almost every particular. Their critique is thoughtful and carefully
done. Nevertheless, it seems to me that in their anxiety to dismiss
our work they missed the point of it. In my presentation I will: (1)
sketch our original model (2) sketch the objections raised by Pinker
and Prince, (3) explain the way in which these objections either miss
the point of our effort or are simply mistaken and finally (4) offer
my account of the real significance of our effort and the possibility
of a connectionist account of linguistic information processing.
--------------
NEXT WEEK'S CSLI SEMINAR
External Language and Internal Representation
Pat Hayes
(Hayes.pa@xerox.com)
October 22
Language evolved, and is used, for communication between intelligent
agents. Internally represented information is used quite differently,
and different assumptions must be made in thinking about ways of
encoding it for use inside a mind. In particular, communication can
assume an intelligent decoder on the other end but is severely
constrained by the bandwidth of speech, while internal representations
seem to have much wider channels of communication available between
their component parts but must be explicit and detailed to an extent
that would be inappropriate for a `natural' language. I will argue
that general talk of `information' ignores this important distinction
and is therefore sometimes confusing in discussions of situated
agency.
-------
∂15-Oct-87 1039 EMMA@CSLI.Stanford.EDU Correction on Locations
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 15 Oct 87 10:39:29 PDT
Date: Thu 15 Oct 87 09:21:43-PDT
From: Emma Pease <Emma@CSLI.Stanford.EDU>
Subject: Correction on Locations
To: friends@CSLI.Stanford.EDU
Tel: (415) 723-3561
Message-ID: <12342704667.35.EMMA@CSLI.Stanford.EDU>
Today's CSLI seminar will be in Room G-19 in Redwood Hall at 2:15 as
are all the rest of the CSLI Seminars this quarter.
Today's Colloquium is in the Ventura Trailers Classroom at 4:15.
Emma Pease
-------
∂15-Oct-87 1135 SCHAFFER@Sushi.Stanford.EDU Meeting with David Johnson
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 15 Oct 87 11:35:36 PDT
Date: Thu 15 Oct 87 11:30:49-PDT
From: Alejandro Schaffer <SCHAFFER@Sushi.Stanford.EDU>
Subject: Meeting with David Johnson
To: aflb.su@Sushi.Stanford.EDU
cc: wilf@Score.Stanford.EDU
Message-ID: <12342728171.18.SCHAFFER@Sushi.Stanford.EDU>
After his talk, Dr. Johnson plans to stay and talk with students.
We may also plan a dinner expedition. Details should be worked out
between now and AFLB. If you would like to talk to Dr. Johnson, but
cannot make it to the talk, check my door (MJH244) for details such as
where he will be sitting and for how long he will stay.
Alejandro
-------
∂15-Oct-87 1405 Kabowen@logiclab.cis.syr.edu Call for Papers
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 15 Oct 87 14:03:12 PDT
Received: from LOGICLAB.CIS.SYR.EDU by navajo.stanford.edu with TCP; Thu, 15 Oct 87 13:57:21 PDT
Received: from cantor.logiclab.cis.syr.edu by goedel.logiclab.cis.syr.edu
id aa01476; 14 Oct 87 16:12 EDT
Date: Wed, 14 Oct 87 16:20:30 EDT
From: Ken Bowen <kabowen@logiclab.cis.syr.edu>
To: nail@navajo.stanford.edu
Subject: Call for Papers
Jeff Ullman suggested I send the following call for papers ----- Ken Bowen
---------------------------------------------------------------------------
CALL FOR PAPERS
ASSOCIATION FOR LOGIC PROGRAMMING
Fifth International Logic Programming Conference
Fifth Symposium on Logic Programming
15-19 August 1988 -- Seattle, Washington
The Association for Logic Programming is sponsoring the first joint
meeting of the two principal Logic Programming conferences. Previous meetings
of the International Conference have taken place in Marseilles, Stockholm,
London, and Melbourne. Previous meetings of the Symposium have taken place
in Atlantic City, Boston, Salt Lake City, and San Francisco.
Authors are invited to submit papers on all aspects of Logic Programming,
including, but not restricted to:
+ Applications
+ Role in Artificial Intelligence
+ Deductive Databases
+ Relations to other computational paradigms
+ Language issues
+ Methodology
+ Implementations on sequential and parallel architectures
+ Theory
Of special interest are applications that exploit the unique character of
logic programming.
PAPERS DUE: 1 February 1988.
============================
Short papers are limited to five double-spaced 10-point pages;
Long papers are limited to twelve double-spaced 10-point pages.
Notification of Acceptance: 9 May 1988.
Camera-Ready Copy Due: 10 June, 1988.
Send five (5) copies of submitted manuscripts to the Program Chairman:
Robert A. Kowalski, LP88
Department of Computing
Imperial College
180 Queen's Gate,
London SW7 2BZ
ENGLAND
For other information contact the Conference Chairman:
Kenneth A. Bowen, LP88
Logic Programming Research Group
School of Computer and Information Science
313 Link Hall
Syracuse University
Syracuse, NY 13210
USA
Authors are also invited to submit proposals for TUTORIALS, both advanced
and introductory. Tutorial sessions may be half or full-day, and will be
conducted on a schedule throughout the week. Tutorial proposals should
include (1) a statement of the proposed topic area, (2) an outline of the
tutorial, (3) relevant bibliography, and (4) proposer's curriculum vita.
Proposals for ADVANCED TUTORIALS are especially encouraged.
Send three (3) copies of tutorial proposals to the Tutorial Chairman:
Veronica Dahl
Department of Computing
Simon Fraser University
Burnaby, B.C.
CANADA
Program Committee:
=================
K. Bowen, Syracuse Univ., USA
A. Ciepielewski, SICS, Sweden
J. Cohen, Brandeis Univ., USA
H. Gallaire, ECRC, Germany
S. Gregory, Imperial College, UK
S. Haridi, SICS, Sweden
R. Kowalski, Imperial College, UK
J-L Lassez, IBM Yorktown, USA
G. Levi, Univ. of Pisa, Italy
J. Levy, Weizmann Institute, Israel
F. Mizoguchi, Science Univ., Tokyo,
R. Nasr, MCC, USA
A. Porto, Univ. of Lisbon, Portugal
K. Ramamohanarao, Melbourne Univ., Australia
M. Sergot, Imperial College, UK
L. Sterling, Case Western Univ., USA
S. Uchida, ICOT, Tokyo, Japan
DHD Warren, Mancester Univ., UK
DS Warren, SUNY at Stony Brook, USA
∂15-Oct-87 1643 TAJNAI@Score.Stanford.EDU Call for Student Speakers, and New Faculty Speakers
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 15 Oct 87 16:43:17 PDT
Date: Thu 15 Oct 87 16:40:14-PDT
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Call for Student Speakers, and New Faculty Speakers
To: faculty@Score.Stanford.EDU
cc: hiller@Score.Stanford.EDU
Message-ID: <12342784499.44.TAJNAI@Score.Stanford.EDU>
CSD/CSL Faculty:
This is the call for speakers for the 20th Annual Computer
Forum Meeting scheduled for February 9-11, 1988. Please send me the
names of your nominees by Sunday, November 1.
First priority goes to PHD students who plan to graduate before the
next Forum meeting (Feb. 1989) and who have never spoken at the Forum
before.
Second priority goes to advanced PHD students who have made significant
progress and have something important to talk about.
Third priority goes to PHD students who have spoken before and who
have new results or new research.
New Faculty are invited to speak:
David Dill, Yoav Shoham, John Mitchell
Jean-Claude Latombe, Andrew Golding, Nanni De Micheli.
Forum sessions will be Wed. a.m. Feb. 10, and all day Thursday, Feb. 11.
Estimate 20 minutes including questions per speaker.
Faculty advisors are expected to introduce their student speakers. If
you will be unable to do so, please ask another faculty member to do the
honors, and let me know.
Ted Shortliffe will present the first Forsythe Lecture on Monday night,
Feb. 8 and the second lecture at 4:15 Tuesday, Feb. 9. An informal
buffet supper will be held at the Faculty Club on Tuesday from 6:00 to
8:00 p.m.
Wednesday morning we will start the conference at 8 a.m. with a buffet
breakfast at Tresidder. Professor Feigenbaum has volunteered to give
a presentation during the Plenary Session which follows the breakfast.
Alan Kay will be our banquet speaker Wed. evening.
A new feature will be a Poster Session scheduled for Wednesday afternoon
in the CERAS lobby. This will give an opportunity for Masters students
and PHD students, who are not ready to give a formal presentation, to
have visibility with our Forum members.
At 4:15 Wednesday afternoon we will have a panel discussion (Dick
Shuey our honorary Forum Committee member is planning that), at the
EE380 seminar in Terman Auditorium. That will be followed at 6 p.m.
with the hospitality time and banquet at the Faculty Club (6-9:30 p.m.)
David Ungar is the Program Chairman, and Craig Cornelius is co-chairman
for the Wednesday afternoon poster session.
All participating students are required to submit a resume to the
Computer Forum Resume Books. Speakers must submit a working title by
December 1, and abstracts and copies of their slides by mid-January.
We are working hard to make our Twentieth Annual Meeting the best ever,
and we ask you to help us make it a big success.
Carolyn
time table:
November 1 nominations must be received
November 15 student speakers will be notified
December 1 working titles due
January 15 abstract of talk and photo ready copies of viewgraphs
February 8 Forsythe Lecture
February 9 Forsythe Lecture - Forum Twentieth Annual Meeting
February 10 Meeting continues
February 11 conclusion: reception at Faculty Club from 4:30-6
p.s. If anyone knows Alan Kay and can suggest a gift for him, I would
appreciate some tips.
-------
∂15-Oct-87 1727 TAJNAI@Score.Stanford.EDU Apologies to Andrew Goldberg
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 15 Oct 87 17:27:40 PDT
Date: Thu 15 Oct 87 17:22:53-PDT
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Apologies to Andrew Goldberg
To: faculty@Score.Stanford.EDU,
Forum-Committee: ;
Message-ID: <12342792262.44.TAJNAI@Score.Stanford.EDU>
Our new faculty member is Andrew Goldberg; Andrew Golding is
one of our PHD students.
Carolyn
-------
∂15-Oct-87 1733 TAJNAI@Score.Stanford.EDU Computer Forum is Number ONE!!
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 15 Oct 87 17:33:34 PDT
Date: Thu 15 Oct 87 17:29:35-PDT
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Computer Forum is Number ONE!!
To: csd.list@Score.Stanford.EDU, csl-everyone@Sierra.Stanford.EDU
Message-ID: <12342793481.44.TAJNAI@Score.Stanford.EDU>
I just got the word from the Development Office. The Computer Forum
is the largest Affiliate Program on campus. We brought in
$1,101,693 in 1986/87; GSB came in next with $1,068,482.
We'll have to work hard to remain #1. Thanks to all who help make
the Forum a success!
Carolyn
-------
∂16-Oct-87 1103 PAPA@Score.Stanford.EDU Any UC people around today?
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Oct 87 11:03:46 PDT
Date: Fri 16 Oct 87 10:58:32-PDT
From: C. Papadimitriou <PAPA@Score.Stanford.EDU>
Subject: Any UC people around today?
To: faculty@Score.Stanford.EDU, phd@Score.Stanford.EDU
Message-ID: <12342984438.35.PAPA@Score.Stanford.EDU>
Dear Colleagues:
I am back for a few days. I have the following unusual query:
Do you know anybody who is an employee of the University of California
(any campus, but not student) and is at Stanford today?
Many thanks. This could save me a four hours trip today....
Regards, ---Christos.
-------
∂16-Oct-87 1133 SF@CSLI.Stanford.EDU
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Oct 87 11:33:40 PDT
Date: Fri 16 Oct 87 11:32:32-PDT
From: Sol Feferman <SF@CSLI.Stanford.EDU>
To: logmtc@Sail.Stanford.EDU
Message-ID: <12342990627.30.SF@CSLI.Stanford.EDU>
Seminar in Logic and Foundations of Mathematics
Speaker: S. Feferman
Topic: Moschovakis' 1984 paper on abstract recursion theory as a
foundation for the theory of algorithms (contd.)
Time: Monday, Oct. 19, 4:15-5:30
Place: Room 381-T, Math Corner, Stanford
-------
∂16-Oct-87 1514 SLOAN@Score.Stanford.EDU [Rosemary Napier <RFN@SAIL.Stanford.EDU>:]
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Oct 87 15:14:05 PDT
Date: Fri 16 Oct 87 15:11:43-PDT
From: Yvette Sloan <SLOAN@Score.Stanford.EDU>
Subject: [Rosemary Napier <RFN@SAIL.Stanford.EDU>:]
To: Faculty@Score.Stanford.EDU
Message-ID: <12343030527.28.SLOAN@Score.Stanford.EDU>
Some of you, I hear, don't know that there's a going-away party for John
Reuling today at 4:15 in Room 252. Well...there is and I hope some of you
can join us. Thanks.
---------------
Return-Path: <RFN@SAIL.Stanford.EDU>
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 15 Oct 87 16:54:22-PDT
Date: 15 Oct 87 1654 PDT
From: Rosemary Napier <RFN@SAIL.Stanford.EDU>
To: "@SEC3.[1,RFN]"@SAIL.Stanford.EDU
To: CSD Staff
From: Rosemary
Re: REMINDER!
John Reuling's going-away party is tomorrow, Friday, Oct. 16 at
4:15 pm in room 252. Program yourself to be there.
-------
∂16-Oct-87 1528 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talks
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Oct 87 15:28:21 PDT
Date: Fri 16 Oct 87 11:00:20-PDT
From: Anil R. Gangolli <GANGOLLI@Sushi.Stanford.EDU>
Subject: Upcoming AFLB Talks
To: aflb.all@Sushi.Stanford.EDU
Office Phone: (415) 723-3605
Message-ID: <12342984764.26.GANGOLLI@Sushi.Stanford.EDU>
THIS WEEK'S TALK:
22-October-87: Thane Plambeck (Stanford)
The Complexity of Nim
and Taking and Breaking Games
We study algorithms for a broad class of impartial two-player perfect
information games known as ``taking and breaking games.'' Included in
this class are the games of Nim, Kayles, Dawson's chess, Treblecross,
and all finite octal and tetral games. No knowledge of these games
will be assumed and the relevant theory will be developed from first
principles. Our results include NC algorithms for an infinite
subclass of taking and breaking games, and a P-completeness result for
the recognition of winning positions of these games when the rules of
the game are specified as part of the input.
***** Time and place: Thurs, October 22, 12:30pm in MJH 352 (Bldg. 460) *****
NEXT WEEK'S TALK:
29-October-87: Ramsey Haddad (Stanford University)
Cyclic $A↑i B C↑i$ Paths
in Labelled Graphs
(Joint work with Jeff Naughton, Princeton University.) This problem
arises in database queries: Given a graph with three types of edges,
A, B, and C, and given a node x_0, find all nodes y that are reachable
from x_0 by a path of the form A↑i B C↑i. Some O(ne) algorithms are
previously known for the case when either the A↑i or the C↑i portion
of the path is acyclic. We will show how to achieve O(ne) time for
the case when *both* the A↑i and C↑i portions are cyclic. This
involves the use of a conglomeration of numeric and graph ideas such
as: strongly connected components, the period of a graph,
intersections of semi-linear sets, and dynamic programming.
***** Time and place: Thurs, October 29, 12:30pm in MJH 352 (Bldg. 460) *****
-------
∂18-Oct-87 0158 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #74
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 18 Oct 87 01:58:39 PDT
Date: Sat 17 Oct 1987 12:34-PDT
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #74
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Sunday, 18 Oct 1987 Volume 5 : Issue 74
Today's Topics:
Announcement - European Perspective & QB1,
Implementations - Argument & Types & Failure & Badness
----------------------------------------------------------------------
Date: Thu, 15 Oct 87 13:34:53 EDT
From: finin@bigburd.PRC.Unisys.COM (Tim Finin)
Subject: PROLOG AND AI APPLICATIONS - A EUROPEAN PERSPECTIVE
AI Seminar
UNISYS Knowledge Systems
Paoli Research Center
Paoli PA
PROLOG AND AI APPLICATIONS - A EUROPEAN PERSPECTIVE
Raf Venken
BIM Prolog
Raf Venken, manager for BIM Prolog Research and Development, will be
visiting Logic Based Systems on Monday, October 19th. BIM is a high
performance Prolog which runs on UNIX-based SUN workstations as well
as VAXES under VMS, UNIX 4.2, and ULTRIX. BIM is involved in joint
research efforts with various universities throughout Europe and is a
member of ESPRIT (the "European MCC"). BIM has also contributed to
LOQUI, a large natural language project.
BIM claims to be the fastest general purpose Prolog system currently
available on the market. BIM includes "the first successful attempt
to include more intelligent debugging aids into the [Prolog] system"
and a "PARTIAL EVALUATION system which optimizes Prolog programs by
source-to-source transformations." BIM has also "extended the Prolog
language with the concept of MODULES to allow the easy development of
very large systems."
The talk will cover the philosophy and strategy behind BIM Prolog,
discuss current ESPRIT projects including a large NLP system, and
speculate about the future.
11:00am, Monday, October 19th
Cafeteria Conference Room
- if you are interested in attending, please send -
- mail to finin@prc.unisys.com or call 215-648-7446 -
------------------------------
Date: Thu, 15 Oct 87 15:13:18 EDT
From: finin@bigburd.PRC.Unisys.COM (Tim Finin)
Subject: OB1: A Prolog-Based Object-Oriented Database
OB1: A PROLOG-BASED OBJECT-ORIENTED DATABASE
Benjamin Cohen
SRI International
David Sarnoff Research Center
Princeton NJ 8540
In this talk I describe OB1, an object-oriented database facility. OB1
is a hybrid query language that incorporates most of the features of
relational query languages plus "view/objects" that allow sets as
values and recursive views. OB1 is implemented in Quintus Prolog and
includes server facilities that allow C & Fortran clients to query an
OB1 server over a SUN network. OB1 also has a graphics
Entity/Relationship data modeling editor used to design OB1 databases.
Ben will be here friday, October 23, from lunch time till 5 - I suppose
the talk would start around 1:30 or 2:00
2:00pm Friday, October 23
Cafeteria Conference Room
- if you are interested in attending, please send -
- mail to finin@prc.unisys.com or call 215-648-7446 -
------------------------------
Date: Thu, 15 Oct 87 12:08:29 BST
From: Fernando Pereira <pereira%cam.sri.com@drakes.ai.sri.com>
Subject: Inappropriate arguments, failure and types
In his latest communication about Lagache's library, after comparing
various Prolog versions of "merge" with an ML version, Richard O'Keefe
makes the comment
PROVIDED that this was documented as ONLY being usable to
compute the third argument from the first two, this would be
tolerable.
Mind you, I find it extremely odd that
merge([], [a], X)
would be reported as an error, but that
merge([], a, X)
would NOT be reported. What is so special about wrong length that
it is the only error that deserves reporting?
It is interesting to note that this problem does not arise in the ML
version, because ML's type system will reject the equivalent ML function
call, since "a" is not a valid list constructor. Now, there's a simple
but rather subtle point here. Even though EXTENSIONALLY a function
is just a special case or a relation, functions in a typed functional
language like ML are always given with their domain and range. In the
ML type system, the type specification
merge: Alpha list x Alpha list -> Alpha list
states that for ANY type Alpha, "merge" guarantees to take any pair of
lists of elements of Alpha to a list of elements of Alpha, PROVIDED
that it terminates. That is, "merge" will not return an object outside
its declared range if it is given objects in its declared domain.
However, the ACTUAL extension of "merge" as defined is smaller, that is,
"merge" is a PARTIAL function from its declared domain to its range.
Operationally, partiality may correspond to exceptions (in the present
example two lists of different lengths) or to nontermination.
One could of course conceive of a richer type system in which "pair
of lists of Alpha with the same length" would be a definable type; "merge"
with such a domain would be total. Unfortunately, in type systems
more fine-grained means less tractable. Clearly, the unsolvability
of the halting problem ensures that with a decidable type system some
functions will partial on their alleged domains. The lesson I want
to draw from these observations is that functions don't "have" types,
rather types are GIVEN to functions as an indication of what the functions
are guaranteed NOT to do: namely, not to return values outside their
range when they are given values in their domain; typecheking is
a means of ensuring that type assignments are consistent.
When we move from functions to relations, things become even less clear.
Whereas one might say that IDEALLY a function should be total on its
declared domain, it's just that the unsolvability of the halting problem
prevents us from giving it the right type, relations are not INTENDED to
be total. What's involved here is a decision as to what properties of
a relation are taken to be NECESSARY and what properties are taken to
be CONTINGENT. For example, we may take it to be necessary that the
"is a divisor of" relation relates integers, but contingent that
7 has no positive divisors except 1 and itself. Then we would argue
that using the relation with non-integer arguments is a "type error"
whereas using it with arguments 3 and 7 is a valid question that just
happens to fail. This issue comes up also in distinguish between
"nonsense" and "falsity" in English statements. As in this case,
the distinction is mostly governed by the intentions of the participants
in the dialogue. Whether "No rock owns a car" is seen as nonsensical
or just trivially true has to do with the states of mind of participants
in the communication act and what they intend to achieve by communicating.
The lesson that I draw from these observations is that one should
distinguish the actual EXTENSION of a relation, as given by its
definition, from its intended domain of applicability as given by
comments or type declarations. The use of "defensible" explicit
failure clauses is redundant and confusing. Predicates SHOULD just
fail if they are given arguments outside their extension; if programmmers
require additional help in recognizing situations where a call
will because its arguments fall outside its intended domain of use,
tools like the O'Keefe-Mycroft typechecker could be used., or indeed
good old-fashioned paper-and-pencil logical reasoning. That is,
typechecking should be seen as an aid to program verification: type
declarations state intended properties of relations (eg. that
if the first two arguments of "merge" are lists the third argument
will also be a list is "merge" succeeds), and type checking verifies
whether the actual program satisfies those (partial) specifications.
-- Fernando Pereira
------------------------------
Date: Fri, 16 Oct 87 23:43:13 PDT
From: quintus!ok@Sun.COM (Richard A. O'Keefe)
Subject: Why so much bad Prolog?
One reader of the Prolog Digest, having seen my recent messages
about some common systematic errors in Prolog programs (if any
of you thinks I think Lagache's code is particularly bad, know
that you are wrong! He has enough comments so that I can see
what he means. That excuses a great deal.) asked me whether I
had any idea why there is so much bad Prolog code around.
I was all set to spout, but it dawned on me: is there any
evidence that Prolog programs tend to be any worse relative to
the obvious canons than programs in any other language? I'm
beginning to wonder. We installed the "news" system recently.
It's great to read articles about C and UNIX and Lisp again.
But two things strikes me forcibly:
Many people sending messages to net.lang.c and the
like know little about spelling and care less.
An amazing number of them seem to have no acquaintance
with English or American grammar. (The two differ:
for example American has "get off of the chair" and
verb-noun modification "walk shorts". English has
neither of these. I'm not complaining about differences
from English grammar; this is America.)
Dijkstra has said that he thinks the two most important
prerequisites for a programmer are a mastery of one's native
language and an aptitude for mathematics (as opposed to having
extensive knowledge of mathematics). I think he is right.
Both of these attributes can be seen as
- caring about getting things RIGHT
- a feeling for rule-governed systems
Dijkstra isn't the only one. H. Beam Piper, in one of the two
"Little Fuzzy" books he completed, has Judge Pendarvis say "It's
all the fault of the English teachers."
"Aptitude for mathematics" shows up in two areas that tend
not to receive much attention: boundary cases and ensuring
that program parts fit together with a minimum of sticky tape.
Someone who would be comfortable thinking in terms of algebras
(even if s/he has never heard of them) will want to ensure that
routines do something sensible with any argument, and will want
to ensure that the outputs and arguments of various pieces are
compatible so that s/he can think in terms of composing operations.
Most of the programs I have seen in any programming language
are rather bad. This even applies to code published in journals
and conferences. I could give examples, but there are libel laws
in this country... Nearly all the C code I have seen was quite
amazingly ugly. If you are using UNIX, you might try using the
look(1) command on a file with very long lines.
/usr/bin/look fred /vmunix
is a good one to try. There are other UNIX commands that are
likely to crash with long lines. I think the worst "published"
code I have ever seen was in the UCSD P-system user-contributed
library. There were programs in that that weren't even FINISHED.
One of the important things you have to realise if you want
to write good code is that you aren't already doing so. We might
list this as another attribute for a programmer
- ability and willingness to regard one's own work critically
Someone who never pulls back from the terminal saying "wait a minute,
this is just too ugly, I must be doing something wrong" is almost
certainly doing something wrong and writing ugly code. It is
necessary to criticise one's own code no matter how expert one thinks
one is in the programming language one is using: there is often a
better algorithm, one may be doing something inconsistently in
different places (e.g. UNIX command options...), it might be better
to write an interpreter, ...
It is also necessary to realise that you never stop learning the
things you can do with your programming language. I've been writing
C for years, and yet only this week I was shown a technique which,
now I've seen it, is obvious, powerful, and about as elegant as C
ever gets. So it is always worth taking a step back from a WORKING
program and asking "could I express that more clearly?"
But criticism of the quality of the code is perhaps a fine point.
Correctness is more important, and here it is vital to be "scientific"
about your code. It is not enough to say "how can I see if this is
working". You have to ask "how can I *break* it?" One of the reasons
why Quintus Prolog is as reliable as it is is that we are continually
looking at the code and asking ourselves "how can I break that?". All
too often there is a way, and we fix it. Sometimes the fix is a hack,
but then the fix often needs fixing later because it doesn't work in
another operating system or whatever. Good fixes make things simpler.
If there IS a special problem with Prolog, I think it is probably
due to the fact that Prolog is DIFFERENT. If you already know Lisp,
SNOBOL or Icon, a pure functional language, and a data base query
language, then Prolog is just more of the same. But if you are a
Pascal programmer, you tend to think you know all about structured
programming, and if the habits that the straitjacket of Pascal has
crippled you into don't work too well in Prolog, you tend to think
that it's Prolog's fault. Wrong. The key point about Prolog is that
the PURE things are fast and the imperative things are slow, which is
the direct opposite of languages like Pascal.
It doesn't really help that a lot of people out there are making
a fast buck writing Prolog textbooks that don't even tell you how to
design a collection of predicates to be managed by assert/1 and
retract/1. They tell you what the operations do (sketchily), and
then leave you on your own as to how to use them. (The answer, by
the way, is to study the data-base literature. Update anomalies
are quite as important in Prolog as in relational databases, and
have the same causes. You also need to bear in mind the difference
between universal and existential null values, and the fact that a
logical variable is a UNIVERSAL null, not an existential one, which
means that using logical variables for nulls is almost always wrong.)
Who will teach the teachers? Until we have more Prolog textbooks
that are at least as good as Sterling & Shapiro or Pereira & Shieber,
we must EXPECT people to write bad Prolog code.
May I suggest that it would be useful to have people commenting
on their experiences with Prolog textbooks in this digest? It would
be particularly good to find out what the worst gaps are. setof/3
and bagof/3 are one obvious example: Sterling & Shapiro are easily
the best about that, and they are a wee bit shaky; Bratko is
seriously misleading. Are there any books which point out that
Definite Clause Grammar rule are a practical tool for list processing
generally, not an esoteric thing exclusively for natural language
processing? Does your favourite textbook tell you that the Prolog
convention is to call 'nl' at the END of lines? (Some programmers
do it at the beginning, which doesn't work too well with other UNIX
or VMS utilities.) Have you ever needed a sorting routine other
than the built-in sort/2 and keysort/2, and did your favourite
textbook tell you that the best general purpose sorting routine
in Prolog is merge sort; did it tell you how to write a merge sort?
Would you like me to tell you?
------------------------------
End of PROLOG Digest
********************
∂18-Oct-87 2320 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com REMINDER -- Tomorrow's Planlunch -- Ramin Zabih
Received: from WARBUCKS.AI.SRI.COM by SAIL.STANFORD.EDU with TCP; 18 Oct 87 23:20:15 PDT
Received: from venice by WARBUCKS.AI.SRI.COM via SMTP with TCP; Sun,
18 Oct 87 22:56:51-PDT
Received: by venice (3.2/4.16) id AA10123 for
planlunch_reminder@WARBUCKS.ai.sri.com; Sun, 18 Oct 87 22:58:40 PDT
Date: Sun 18 Oct 87 22:58:38-PDT
From: Amy Lansky <LANSKY@venice.ai.sri.com>
Subject: REMINDER -- Tomorrow's Planlunch -- Ramin Zabih
To: planlunch_reminder@WARBUCKS.ai.sri.com
Message-Id: <561621518.0.LANSKY@VENICE.ARPA>
Mail-System-Version: <SUN-MM(213)+TOPSLIB(128)@VENICE.ARPA>
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
DEPENDENCY-DIRECTED BACKTRACKING IN NON-DETERMINISTIC LISP
Ramin Zabih (RDZ@SUSHI.STANFORD.EDU)
Computer Science Department
Stanford University
11:00 AM, MONDAY, October 19
SRI International, Building E, Room EJ228
Dependency-directed backtracking is a strategy for solving
generate-and-test search problems. Pure Lisp extended with McCarthy's
non-deterministic operator AMB is an elegant language for expressing
such problems. I will describe how to automatically provide
dependency-directed backtracking in SCHEMER, a non-deterministic Lisp
dialect.
It is also possible for SCHEMER to automatically provide other search
strategies than dependency-directed backtracking. In fact, SCHEMER
can support a large class of solution methods. I will show that
SCHEMER programs can make use of any algorithm for determining the
satisfiability of a propositional formula in Conjunctive Normal Form.
This is joint work with David McAllester.
-------
∂19-Oct-87 1055 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Wanted: Voronoi diagram construction routine.
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 19 Oct 87 10:55:22 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Mon 19 Oct 87 10:44:35-PDT
Received: by lindy.stanford.edu; Mon, 19 Oct 87 10:44:24 PDT
Received: by Forsythe.Stanford.EDU; Mon, 19 Oct 87 10:32:08 PDT
Received: by NDSUVM1 (Mailer X1.24) id 0211; Mon, 19 Oct 87 12:20:43 CDT
Date: 19 Oct 1987 13:12:51-EDT (Monday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Christian S. Collberg" <COLLBERG%DNA.LU.SE%MCVAX.BITNET@forsythe.stanford.edu>
Subject: Wanted: Voronoi diagram construction routine.
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
I'm looking for a routine that constructs the Voronoi diagram from a set of
points. It will be used to process geological data, approx 500 pts. Pascal
or FORTRAN preferred, but other languages would be OK, too. Contact me by
email.
Thanks.
Chris Collberg
{mcvax, enea}collberg@dna.lu.se
∂19-Oct-87 1305 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Seminar in Applications of Logic to Computer Science
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 19 Oct 87 13:05:28 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Mon 19 Oct 87 12:56:34-PDT
Received: by lindy.stanford.edu; Mon, 19 Oct 87 12:56:23 PDT
Received: by Forsythe.Stanford.EDU; Mon, 19 Oct 87 12:58:32 PDT
Received: by NDSUVM1 (Mailer X1.24) id 4668; Mon, 19 Oct 87 14:55:18 CDT
Date: 19 Oct 1987 15:48:44-EDT (Monday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Rohit Parkih <RIPBC%CUNYVM.BITNET@forsythe.stanford.edu>
Subject: Seminar in Applications of Logic to Computer Science
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
SEMINAR IN APPLICATIONS OF LOGIC TO COMPUTER SCIENCE
This seminar meets at the City University Graduate Center, 33 W
42nd Street, New York, room 1223, Tuesdays from 11-12:30 (app). The next
meetings will be:
Oct 20, No meeting
Oct 27, Rohit Parikh, Some extensions of Kripke's theory of Truth
Nov 3, W. Zarodzny (IBM-YKT), 3 level semantics and its applications
∂19-Oct-87 1547 BSCOTT@Score.Stanford.EDU Reminder, Tuesday Lunch
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 19 Oct 87 15:46:41 PDT
Date: Mon 19 Oct 87 15:44:26-PDT
From: Betty Scott <BSCOTT@Score.Stanford.EDU>
Subject: Reminder, Tuesday Lunch
To: Faculty@Score.Stanford.EDU
Message-ID: <12343822915.18.BSCOTT@Score.Stanford.EDU>
Reminder that tomorrow's lunch will be at 12:15 in MJH146, and that
Elizabeth Batson, Manager of Software Licensing, OTL, will join us.
Nils
-------
∂20-Oct-87 1003 ULLMAN@score.stanford.edu Paper available
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Oct 87 10:02:58 PDT
Received: from Score.Stanford.EDU by navajo.stanford.edu with TCP; Tue, 20 Oct 87 09:59:02 PDT
Date: Tue 20 Oct 87 09:59:15-PDT
From: Jeffrey D. Ullman <ULLMAN@score.stanford.edu>
Subject: Paper available
To: nail@navajo.stanford.edu
Message-Id: <12344022222.38.ULLMAN@Score.Stanford.EDU>
"YAWN! (yet another window on NAIL!)", K. Morris, J. Naughton,
Y. Saraiya, J. Ullman, A Van Gelder.
This is our latest report on what's going on with the NAIL! project.
Copies are available from Rosemary NApier (rfn@sail.stanford.edu)
---jdu
-------
∂20-Oct-87 1018 ULLMAN@score.stanford.edu Papers received
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Oct 87 10:18:03 PDT
Received: from Score.Stanford.EDU by navajo.stanford.edu with TCP; Tue, 20 Oct 87 10:13:27 PDT
Date: Tue 20 Oct 87 09:57:03-PDT
From: Jeffrey D. Ullman <ULLMAN@score.stanford.edu>
Subject: Papers received
To: nail@navajo.stanford.edu
Message-Id: <12344021820.38.ULLMAN@Score.Stanford.EDU>
M. Nussbaum and H.-J. Appelrath, "Delayed evaluation of function free
linear Horn clauses" ETH, Zurich
This one is a puzzle. They seem to be talking about lazy evaluation,
without ever using the term. Yet they also envision expansion
of a rule/goal tree completely, to ground atoms, followed by
evaluation up the tree (I guess pruning branches where appropriate).
P. G. Kolaitis and C. H. Papadimitriou, "Why not negation by fixpoint?"
Stanford Univ.
The answer is: because it sometimes gives unintuitive result.
The intent of the paper is to produce a fixed point of all facts
that are inferred on ANY round of naive evaluation, starting with
empty IDB relations.
---jdu
-------
∂20-Oct-87 1636 @RELAY.CS.NET:DUSSUD@jenner.csc.ti.com Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 20 Oct 87 16:36:09 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ae00813; 20 Oct 87 18:19 EDT
Received: from csl.ti.com by RELAY.CS.NET id ah15609; 20 Oct 87 18:17 EDT
Received: from Jenner by tilde id AA13643; Tue, 20 Oct 87 16:18:06 CDT
Message-Id: <2770752076-11152612@Jenner>
Date: Tue, 20 Oct 87 16:21:16 CDT
From: Patrick H Dussud <DUSSUD%jenner.csc.ti.com@RELAY.CS.NET>
To: dcm%hpfclp@hplabs.hp.com
Cc: x3j13@SAIL.STANFORD.EDU
Subject: Re: November X3J13 meeting
In-Reply-To: Msg of Wed, 16 Sep 87 15:39:35 cdt from tilde::@relay.cs.net, @sail.stanford.edu:dcm%hpfclp@hplabs.hp.com
X3J13 NOVEMBER MEETING REGISTRATION FORM
Name: Patrick Dussud
Institution: Texas Instruments Austin.
Street Address: 12501 research Blvd
City, State, Zip: Austin TX 78759
Phone: (512) 250-7483
Network Address: Dussud%jenner%ti-csl.csnet
Dinner 11/17 (y/n): N__________________________________________________
First choice: __________________________________________________
Second choice: __________________________________________________
(Duck, chicken, shrimp, sirloin, salmon, lamb, vegetarian)
Dietary Restrictions: __________________________________________________
__________________________________________________
__________________________________________________
∂20-Oct-87 2045 REGES@Score.Stanford.EDU TV students
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Oct 87 20:45:43 PDT
Date: Tue 20 Oct 87 20:42:49-PDT
From: Stuart Reges <REGES@Score.Stanford.EDU>
Subject: TV students
To: faculty@Score.Stanford.EDU
Office: CS-TAC 22, 723-9798
Message-ID: <12344139379.11.REGES@Score.Stanford.EDU>
I am considering changing our policy about NCO admissions, so I wanted to send
out a general note of warning to see if there is an objection. I propose that
we remove our restrictions for NCO TV students, that we allow anyone to take a
course from us as an NCO, even if they have no undergrad degree and even if
they have a low GPA in previous coursework. Let me explain in more detail for
those who aren't familiar with the terms.
There are three kinds of TV students, two of which don't cause a problem.
Auditors are just supposed to listen, so they aren't allowed to bother us or
complain. Honors CoOp students are in our MS program (and even sometimes PhD),
but they go through the normal admissions process, which tends to guarantee a
fairly high caliber of student. The in-betweens are the NCO students: Non
Credit Option. They are treated like credit students in that we grade their
homeworks and give them a grade at the end of the quarter, but they receive 0
units. They are difficult in the sense that they want to ask questions of TAs
and we have to grade their homework. If they are inadequately prepared, they
can possibly generate extra work. For that reason, the TV network has
traditionally required that NCO students have an undergraduate degree and that
they have a 3.0 GPA in their undergrad work. Students must apply for the right
to take a course as an NCO. One of my staff members goes through NCO
applications and checks to make sure they have the minimum 3.0 GPA. We often
get complaints from people who are turned down, so we have to decide whether or
not to make an exception. We often hear things like, "I was young and immature
when I got those C's, and now I've learned how to work." To apply for NCO, a
student has to be recommended by his/her company, so at least someone besides
the student believes that she/he can do the work.
EE is changing their policy. Starting next quarter, students will be able to
register as NCO students no matter what undergrad GPA they earned. As I
mentioned above, I suggest that we go even further and remove both the GPA
restriction and the undergrad degree restriction (we offer many courses like
CS106 and CS108 that don't require that much background). The good things are
that we can simplify NCO admissions (no more transcripts to read and no more
complaints) and we can potentially increase TV revenues. My guess is that this
will increase TV revenues something like 10-20%, which means $50-100K per year.
If you have any opinions on this possible change, please send them to me. If
this is going to be controversial, maybe we should save it for a faculty lunch
where we can discuss it interactively.
-------
∂20-Oct-87 2053 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu electronic NSF reviews
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Oct 87 20:53:29 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 20 Oct 87 20:45:40-PDT
Received: by lindy.stanford.edu; Tue, 20 Oct 87 20:50:08 PDT
Received: by Forsythe.Stanford.EDU; Tue, 20 Oct 87 20:47:48 PDT
Received: by NDSUVM1 (Mailer X1.24) id 5140; Tue, 20 Oct 87 22:41:35 CDT
Date: 20 Oct 1987 23:38:34-EDT (Tuesday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Carl H. Smith" <CHSMITH@note.nsf.gov>
Subject: electronic NSF reviews
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
The National Science Foundation is now prepared to accept reviews
of research proposals via the electronic mail system. Such a
review should be sent directly to the program manager requesting
the review. The review should contain the proposal number as well
as the text of the review and an overall rating. The official
foundation policy is that the name of the investigator and the
title of the proposal should appear in the message as the second
and third lines, immediately after the proposal number and before
the text of the review. In light of possible security problems
while the electronic review is in transit, I will accept
electronic reviews without a title and investigator name in the
message.
Carl Smith
∂20-Oct-87 2123 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu The Funding of Theory
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Oct 87 21:23:00 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 20 Oct 87 20:56:17-PDT
Received: by lindy.stanford.edu; Tue, 20 Oct 87 21:00:44 PDT
Received: by Forsythe.Stanford.EDU; Tue, 20 Oct 87 20:57:19 PDT
Received: by NDSUVM1 (Mailer X1.24) id 6045; Tue, 20 Oct 87 22:43:54 CDT
Date: 20 Oct 1987 23:38:41-EDT (Tuesday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Carl H. Smith" <CHSMITH@note.nsf.gov>
Subject: The Funding of Theory
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
As most everyone in the community is aware of, the funding of
theoretical computer science by the National Science Foundation
has been eroding rapidly in recent years. In order to reverse
the trend, it is necessary to answer the question: What has the
theory community done for computer science in general, for
science in general, for the good of the country, for motherhood
and apple pie? I will compile a list of answers to present to
the proper authorities (the ones with the money). Ideally, the
list (when finished) will contain short paragraphs, each
describing a result and its significance without the use of
subscripts or superscripts. Input for this list is hereby
requested.
∂21-Oct-87 0850 RICHARDSON@Score.Stanford.EDU Softerware Licensing
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 Oct 87 08:50:28 PDT
Date: Wed 21 Oct 87 08:47:43-PDT
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: Softerware Licensing
To: faculty@Score.Stanford.EDU
Message-ID: <12344271344.13.RICHARDSON@Score.Stanford.EDU>
I have various software licensing handouts in my office available for pickup
by those interested.
-Anne
-------
∂21-Oct-87 0859 RICHARDSON@Score.Stanford.EDU Student Profiles
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 Oct 87 08:59:20 PDT
Date: Wed 21 Oct 87 08:57:05-PDT
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: Student Profiles
To: faculty@Score.Stanford.EDU
Message-ID: <12344273048.13.RICHARDSON@Score.Stanford.EDU>
I have a series of profiles of the top entering American EE graduate
students for 1987 from Rick Reis for anyone who'd like to stop by and take
a peek at it.
-Anne
-------
∂21-Oct-87 0912 RICHARDSON@Score.Stanford.EDU NSF Program Announcement
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 Oct 87 09:12:07 PDT
Date: Wed 21 Oct 87 09:04:45-PDT
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: NSF Program Announcement
To: csd-list@Score.Stanford.EDU
Message-ID: <12344274442.13.RICHARDSON@Score.Stanford.EDU>
I have a proposal from NSF as follows:
Undergraduate Science, Engineering, and Mathematics Education
CAREER ACCESS OPPORTUNITIES IN SCIENCE AND TECHNOLOGY FOR WOMEN,
MINORITIES AND THE DISABLED.
Anyone interested may drop by a make a copy.
-Anne
-------
∂21-Oct-87 2043 BARWISE@CSLI.Stanford.EDU 2 things
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 Oct 87 20:42:57 PDT
Date: Wed 21 Oct 87 20:32:41-PDT
From: Jon Barwise <BARWISE@CSLI.Stanford.EDU>
Subject: 2 things
To: ssp-faculty@CSLI.Stanford.EDU
Message-ID: <12344399679.19.BARWISE@CSLI.Stanford.EDU>
First, thanks for coming to the lunch with the students last week.
There were 45 people there at one point, so at least 25 students. It
interests me that in this program the students really like talking
to the faculty. It was great that so many of you could come.
The other thing was just to remind you of the reception for the
development lab and CAT tomorrow at 4:30, for those of you who are
interested in possibly being involved with students in the development
of software.
Jon
-------
∂22-Oct-87 0839 ROSENKING@A.ISI.EDU Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 22 Oct 87 08:39:11 PDT
Date: 22 Oct 1987 11:36-EDT
Sender: ROSENKING@A.ISI.EDU
Subject: November Meeting
From: ROSENKING@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]22-Oct-87 11:36:22.ROSENKING>
To all those planning to attend the November meeting:
If anyone is interested in indulging in some pre-meeting skiing, on
Saturday and Sunday (Nov. 14-15) at Breckenridge or Keystone mountains
in Colorado, drop me some mail. I am gathering accomodation and prime
ski condtion information at this time and I plan on making reservations
shortly.
All are welcome ! Lisp experience is a plus, though not for skiing ?!
- Jeff Rosenking
∂22-Oct-87 1038 EMMA@CSLI.Stanford.EDU CSLI Calendar, Oct. 22, 3:4
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 22 Oct 87 10:38:44 PDT
Date: Thu 22 Oct 87 09:09:09-PDT
From: Emma Pease <Emma@CSLI.Stanford.EDU>
Subject: CSLI Calendar, Oct. 22, 3:4
To: friends@CSLI.Stanford.EDU
Tel: (415) 723-3561
Message-ID: <12344537389.12.EMMA@CSLI.Stanford.EDU>
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
22 October 1987 Stanford Vol. 3, No. 4
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 22 October 1987
12 noon TINLunch
Ventura Hall Reading: "On Language and Connectionism:
Conference Room Analysis of a Parallel Distributed Processing
Model of Language Acquisition"
by Steven Pinker and Alan Prince
Discussion led by Dave Rumelhart
(der@psych.stanford.edu)
This TINLunch is a follow up of the seminar
that was given on 15 October. Please
see the abstract for it in last week's Calendar.
2:15 p.m. CSLI Seminar
Room G-19 External Language and Internal Representation
Redwood Hall Pat Hayes (Hayes.pa@xerox.com)
Abstract in last week's Calendar
3:30 p.m. Tea
Ventura Hall
--------------
CSLI ACTIVITIES FOR NEXT THURSDAY, 29 October 1987
12 noon TINLunch
Ventura Hall Reading: "Cognitive Significance and New Theories
Conference Room of Reference"
by John Perry
Discussion led by Bob Moore
(bmoore@sri.com)
Abstract in next week's Calendar
2:15 p.m. CSLI Seminar
Room G-19 An Introduction to Situated Automata
Redwood Hall Part I: Basic Concepts
Stan Rosenschein (Stan@warbucks.ai.sri.com)
Abstract below
3:30 p.m. Tea
Ventura Hall
--------------
NEXT WEEK'S SEMINAR
An Introduction to Situated Automata
Part I: Basic Concepts
Stan Rosenschein
October 29
This is the first of two lectures on the situated-automata approach to
the analysis and design of embedded systems. This approach seeks to
ground our understanding of embedded systems in a rigorous, objective
analysis of their informational properties, where information is
modeled mathematically in terms of correlations between states of the
system and conditions in the environment. In this talk we motivate the
general framework, present the central mathematical ideas on how
information is carried in the states of automata, and relate the
mathematical properties of the model to key theoretical issues in AI
including the nature of knowledge, its representation in machines, the
role of syntactic deduction, "nonmonotonic" reasoning, and the
relation of knowledge and action. Some general technological
implications of the approach, including reduced reliance on
conventional symbolic inference and increased opportunities for
parallelism, will be discussed.
The second lecture will describe the application of the
situated-automata perspective to specific problems arising in the
design of integrated intelligent agents, including problems of
perception, planning and action selection, and linguistic
communication.
-------
∂22-Oct-87 1137 DEWERK@Score.Stanford.EDU Course Notes Policy
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 22 Oct 87 11:37:51 PDT
Date: Thu 22 Oct 87 11:34:52-PDT
From: Gerda de Werk <DEWERK@Score.Stanford.EDU>
Subject: Course Notes Policy
To: instructors@Score.Stanford.EDU, tas@Score.Stanford.EDU
cc: dewerk@Score.Stanford.EDU
Message-ID: <12344563914.18.DEWERK@Score.Stanford.EDU>
This is to remind you of the CSD policies for course notes charges.
1) Students are not charged for homework assignments, sample
solutions, and exams.
2) For other handouts, the first 50 pages are free and
students should be charged 3 cents/page thereafter.
3) Estimate the total number of copies at the beginning of the
quarter and charge them at that time.
4) Checks should be made payable to "Stanford University" and
please note the course number on the check.
5) The Instructor or TA should collect the checks and bring them
to Cheryl Ritter (TAC Secretary). (Please do not hold onto the
checks too long.)
PLEASE NOTE: If you have a packet which will require a minimum of
10,000 pages, there is a service which will make the copies and sell
them directly to the students at 3 cents/page. For more information
about this service, please contact GODOT at 856-6138.
Thank you for your cooperation.
-Gerda
-------
∂22-Oct-87 1940 @Score.Stanford.EDU:pratt@chehalis.stanford.edu CS300 lecturers take note
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 22 Oct 87 19:40:09 PDT
Received: from chehalis.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 22 Oct 87 19:35:52-PDT
Received: by chehalis.stanford.edu (3.2/SMI-3.2)
id AA03203; Thu, 22 Oct 87 17:25:31 PDT
Date: Thu, 22 Oct 87 17:25:31 PDT
From: Vaughan Pratt <pratt@chehalis.stanford.edu>
Message-Id: <8710230025.AA03203@chehalis.stanford.edu>
To: faculty@score.stanford.edu
Subject: CS300 lecturers take note
Both last week's and this week's CS300 lecturers turned up with
overhead transparencies expecting that projection facilities would be
available. Neither an overhead projector nor a screen is provided
for. If you need projection facilities (a) bring a projector and (b)
move the class to the adjoining room where there is a screen. (Perhaps
CS300 could be moved permanently to a room with a screen, or phys.plant
or whoever could be asked to put the screen back up in that room,
320-334.)
-v
∂23-Oct-87 1216 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Error-correcting codes
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Oct 87 12:16:09 PDT
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Fri 23 Oct 87 12:06:22-PDT
Received: by lindy.stanford.edu; Fri, 23 Oct 87 11:11:34 PDT
Received: by Forsythe.Stanford.EDU; Fri, 23 Oct 87 11:11:19 PDT
Received: by NDSUVM1 (Mailer X1.24) id 5626; Fri, 23 Oct 87 13:04:35 CDT
Date: 23 Oct 1987 13:57:46-EDT (Friday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Sandeep Sen <DUKE!SS@mcnc.org>
Subject: Error-correcting codes
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
I need some information regarding the best known bounds for maximizing the
(Hamming) distance between two k bit 0-1 codes when the number of
k-bit code words is N (N << 2 sup k).
To be more precise, given 'N' 0-1 vectors of length 'k',
I need to maximize the distance 'd' between the closest pair.
(This is also known as the sphere-packing problem).
Please send your replies by e-mail to ss@cs.duke.edu. Any references
to improvement in bounds over Hamming's original paper
will be greatly appreciated.
--
--------------------------------------------------------------------------
arpa : ss@cs.duke.edu | us-snail: 311 s.la salle st.
csnet : ss@duke | apt 14e. durham nc 27705.
uucp : ...decvax!mcnc!duke!ss | (919)-383-0119.
∂23-Oct-87 1435 @Score.Stanford.EDU:CORNELIUS@SUMEX-AIM.STANFORD.EDU Your BIG chance!
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Oct 87 14:35:41 PDT
Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Fri 23 Oct 87 14:27:32-PDT
Date: Fri, 23 Oct 87 14:31:38 PDT
From: Craig Cornelius <Cornelius@SUMEX-AIM.STANFORD.EDU>
Subject: Your BIG chance!
To: students@SCORE.STANFORD.EDU, csl-students@SIERRA.STANFORD.EDU
cc: faculty@SCORE.STANFORD.EDU
Message-ID: <12344858238.17.CORNELIUS@SUMEX-AIM.STANFORD.EDU>
The 20th Annual Meeting of the Stanford Computer Forum will be held
February 9 - 11, 1988 at Stanford. Representatives from the
approximately 70 companies will attend, and you have an opportunity to
participate.
In addition to several formal talks by students and faculty, this
year's program includes a student poster session, tentatively
scheduled for the afternoon of Wednesday, Feb. 10. On behalf of the
Forum Committee, I invite all of you PhD, MSCS, and MSAI students
involved in research to present your work at that session.
The poster session is an exciting opportunity for you to share your
research, learn about other research in our departments, and defend
your ideas to a tough audience. The Knowledge Systems Laboratory has
included this activity in its 3-day retreats in recent years, and it
has been consistently rated as one of the best parts of the retreat.
The format is informal: Posters are displayed around a large room (in
CERAS Hall, we think). At any given time, about 1/2 of the posters
are accompanied by a presenter, who answers questions and explains the
research to any and all who stop by. There will be at least two time
segments for the session so students will have the opportunity
to browse as well as discuss their own posters.
You should work out the topic and format of your poster in
consultation with your research director. If several people from the
same project will show posters, they may want to coordinate the
presentations. The poster should be on ONE sheet of poster board.
Plan to present the material at the level of an intelligent audience,
generally knowledgable about computers, but not acquainted with the
particular problem and project you are presenting. Don't write a
speech (at least not a long one) but do have a plan for discussing the
poster (don't just read it to the audience) and answering questions.
Above all, your poster should clearly communicate the problem you are
considering, your approach, progress, results and conclusions, and
future plans. It should be attractive, since you want to attract the
interest of people walking by. Of course, charts, graphs, and
pictures are much more effective and interesting than tables of
numbers or sentences on a piece of paper. You should particularly try
to avoid paragraphs of text - itemized or enumerated lists of ideas
expressed as SHORT, CONSISE statements (not necessarily sentences) are
often best.
Use your imagination and creativity. At the KSL retreat, posters
included overlapping windows (mechanical, not CRTs), linked structures
(with string), and even a 3-D representation of a problem-solving
architecture (hanging from the ceiling.)
I have agreed to be the "czar" of this activity and I am compiling a
list of collecting a participants. If you intend to be in the poster
session, I need to know: (a) your name, (b) your topic, (c) your
advisor, prefereably by the end of Fall quarter. Although there are
still 3-1/2 months until the Forum Meeting, I encourage you to develop
a plan for your poster very soon, and begin working on organization
and topic NOW. The space for this poster session is limited, and I
need to make plans soon.
With your enthusiasm and help, this poster session can be an important
part of the Forum Meeting, and a good chance to learn what we are all
about, as well as to share with the industrial affiliates.
Please let me know ASAP if you would like to partipate in this
opportunity. Also, please feel free to contact me with questions and
suggestions about this (E-mail is easiest.) If you'd like to see some
examples, I have several excellent posters that you can examine
prepared by KSL students.
Craig Cornelius
Research Associate
Knowledge Systems Laboratory
725-3860
-------
∂24-Oct-87 1803 SF@CSLI.Stanford.EDU logic seminar
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Oct 87 18:03:51 PDT
Date: Sat 24 Oct 87 18:03:43-PDT
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: logic seminar
To: logmtc@Sail.Stanford.EDU
Message-ID: <12345158990.12.SF@CSLI.Stanford.EDU>
Feferman will continue on Moschovakis' paper (still!). Monday Oct 26
at 4:15 in Room 381-T, Stanford Math Corner.
-------
∂25-Oct-87 0156 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #76
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 25 Oct 87 01:56:25 PST
Date: Sat 24 Oct 1987 10:01-PDT
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #76
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Sunday, 25 Oct 1987 Volume 5 : Issue 76
Today's Topics:
Query - Backslapping & Difference List & Modules,
& Variadic Predicates & Parallelism,
Standardization - Terminology,
Implementation - Aggregates & Meaning
----------------------------------------------------------------------
Date: 2 Oct 87 13:25:01 GMT
From: ihnp4!chinet!fmsrl7!metavax!umich!dwt@ucbvax.Berkeley.EDU
(Dave West)
Subject: O'Keefe's criticism of Lagache's code.
Richard O'Keefe's contributions to the Prolog community have been immense,
but the depth of knowledge that he has is all but unattainable by the rest
of us, who haven't spent years at a Prolog centre and been involved with
several implementations. I think it would be great if he wrote the Prolog
equivalent of Steele's and Sussman's Lisp implementation papers; but since
he's in the commercial world, he probably won't. (Warren's papers are
only for the very dedicated.)
-- David West
------------------------------
Date: Thu 22 Oct 87 05:31:05-EDT
From: vijay <Vijay.Saraswat@C.CS.CMU.EDU>
Subject: Returning difference list.
Something has always bothered me about Prolog-20. Why don't the
systems procedures that return lists (such as name/2) always return
difference lists (name/3)?
------------------------------
Date: 18 Oct 87 20:16:26 GMT
From: sakthi@sally.utexas.edu (Sakthi Subramanian)
Subject: modules in Prolog
I am looking for literature on introducing modules in Prolog (or its
variants). Does anybody have any suggestions?
Thank you.
-- Sakthi
------------------------------
Date: 23 Oct 87 16:05:00 EDT
From: Andre (A.N.) Vellino <VELLINO%BNR.BITNET@forsythe.stanford.edu>
Subject: variadic predicates
I was wondering if anyone on the Digest could think of a good reason for
objecting to the idea of a Prolog that has
a) functors with variable arity (the only one that springs
to mind is that it is simple to emulate variadic predicates
with lists);
b) variable functors (so that, for example "?- Functor(Arg)."
is a valid query).
-- Andre Vellino
------------------------------
Date: 8 Oct 87 22:14:54 GMT
From: sunybcs!lakshman@ames.arpa (T. Lakshman)
Subject: Parallel Logic Programming
I have been investigating architectures for Parallel Logic Programs.
In this context I am looking for information on Parallel Architectures
and Algorithms for Logic Programs.
Thank you.
-- T.K.Lakshman
------------------------------
Date: 12 Oct 87 15:00:50 GMT
From: eagle!icdoc!doc.ic.ac.uk!cdsm@ucbvax.Berkeley.EDU
Subject: A question of terminology
Earlier I posted to the net the draft version of the Prolog Glossary
prepared for the BSI standardization project but it generated only
general murmurs of discontent. I would therefore like to try to
clarify the discontent felt at Imperial College and other centres
which approach Prolog from a background of logic.
The biggest problem is with the word "atom".
atom One of a set of unstructured objects whose only property
is that equality of two elements can be determined.
Apart from minor quibbles about this definition (does it apply to
numbers?), the word 'atom' or 'atomic formula' have traditionally been
used to describe what is here termed a literal:
literal A predicate of arity N and a sequence of N
arguments.
This definition is almost, but not quite, right. In resolution
terminology, a literal is either a predicate with arguments or its
negation (and thus postive or negative literals). But it shows that a
term is needed for this object. In most Edinburgh systems (and I take
the current Quintus manual as the current example) the only
terminology used is compound term:
compound term A functor of arity N together with a sequence of N
arguments.
The word term is used universally in this sense but there is a strong
distinction with formulas built up using logical connectives (and, or
etc), which Edinburgh systems do not recognize as being distinct.
Question: Where does the Edinburgh usage of 'atom' arise from, since there
is a long history of 'atom' meaning a term consisting of a predicate?
(from Lisp?)
We can certainly derive a long list of precedents on both sides:
Logic: Robinson(1965), Kowalski (1979), Hogger(1984), LLoyd (1984),
Charniak, McDermott(1985), Gallier(1986)
Edinburgh: DEC-10 Prolog Manual (1978), Clocksin, Mellish(1981), Sterling,
Shapiro (1986), Bratko (1986) etc.
Note: If anyone can invoke O'Keefe's "Don't kick the craftsman in the
teeth" rule, it is the logicians.
Proposal: The only way to resolve this conflict is to avoid the term
'atom' as far as possible. A possible lead is given by Giannesini, Kanoui,
Pasero, van Caneghem (1986) who call the basic objects "identifiers"- a
well-known and unambiguous computing term. The logical terms are
"constant" or "individual constant", but these can equally apply to
identifiers or numbers, as is universally recognized (and "constant"
should certainly be used in place of "atomic" as the predicate for this).
It is slightly complicated by the fact that an identifier can be an
arbitrary sequence of characters within single quotes, but this needn't be
fatal. Also a variable may be denoted by an identifier; but in this case
its identifier is precisely the individual constant we are talking about.
We also need a term for "atomic formula", as it is has been agreed to
distinguish these clearly from other terms in the standard. Here it would
seem possible to use the word "predication" (following Robinson, 1979).
This distinguishes it from "predicate", which by itself means the set
denoted by the predicate symbol. It's not reasonable to use predicate to
denote symbol+arity in contradistinction to predicate symbol, as is
proposed and we certainly shouldn't follow Sterling, Shapiro and call them
"goals" as this thoroughly confuses the thing with the usage.
I therefore propose the following (please feel free to improve the wording):
identifier A basic unstructured object which can be used to identify an
individual or name of a function or predicate.
predicate symbol An identifier and an arity, associated with a predication.
predicate (deleted)
predication A term consisting of a predicate symbol
and a list (possibly empty) of arguments
function symbol An identifier and an arity associated with a function
functor (deleted)
functor symbol (deleted)
constant An identifier, number or string
goal A predicate which appears in the body of a clause or a query.
literal (deleted)
connective A logical operator used to combine predications into rules
and queries.
query One or more goals and connectives given as interactive input
to the top level. Variable substitutions found while
executing the query may be output.
Comments please!
-- Chris Moss
------------------------------
Date: 5 Oct 87 10:41:33 GMT
From: mcvax!enea!ttds!draken!sics!lhe@uunet.uu.net (Lars-Henrik
Eriksson)
Subject: Standard of Prolog code
In at least one "high-powered commercial Prolog system" naive reverse
suffers a 35% slowdown (on a SUN) when you change append/3 to
append([],L,L).
append([H|L1], [H|L2], L3) :- append(L1, L2, L3).
i.e. change the order of the second and third arguments! The slowdown
of append itself is obviously greater, although I haven't made any
measurements. Apparently poor handling of inline predicates isn't the
only thing that's going on...
-- Lars-Henrik Eriksson
------------------------------
Date: 13 Oct 87 15:16:51 GMT
From: munnari!mulga!philip@uunet.uu.net (Philip Dart)
Subject: aggregates
Richard O'Keefe writes about aggregate/3 in Quintus Prolog
As well as solutions/3, setof/3, bagof/3 and findall/3, NU-Prolog provides
four aggregate functions: count/3, max/3, min/3 and sum/4
Arguments to these predicates fall into the following categories.
Goal: This acts as a generator, producing solutions of the form Term.
Term: The aggregate is concerned only with distinct instantiations of Term.
Subterm: What the aggregate operation, eg. + or >, is applied to.
Result: What the result of the aggregate is unified with.
count/3 is concerned only with `how many' of something there is; it can
therefore make use of just three of these arguments:
count(Term, Goal, Result)
eg. count(Term, member(Term, [pear, apple, orange, pear]), 3).
max/3 (and similarly min/3) needs to apply a comparison operation to
some term, but repeated occurrences of any term will not change the result:
max(Subterm, Goal, Result)
eg. max(Subterm, member(Subterm, [1, 2, 3, 4, 2, 2, 1]), 4).
sum/4 requires all four arguments: Consider trying to find the sum of the
salaries of all employees in 'sales' or 'service'. If some employee
is in both departments, we still only want to include his salary once
(unless of course he is paid by both :-).
employs(sales, fred). paidTo(fred, 10000).
employs(sales, bill). paidTo(bill, 20000).
employs(service, harry). paidTo(harry, 30000).
employs(service, bill).
sum(Salary, Emp-Salary,
some Dept (
(Dept = sales ; Dept = service),
employs(Dept, Emp),
paidTo(Emp, Salary)
),
60000).
(The use of 'some' simply indicates that the variable Dept is used only
in the Goal in the aggregate.)
In general, sum/4 has the form:
sum(Subterm, Term, Goal, Result)
but since Subterm (or at least all the variables in it) would always
have to be repeated in Term, sum/4 uses the combination of its first
two arguments in looking for unique solutions.
For this reason, in the above example, Emp-Salary should be replaced
by Emp.
A final example:
sum(S*3, T,
member(T/S, [orange/10, pear/100, apple/1, apple/1, apple/1000]),
3333).
count/3 can be defined trivially in terms of sum/4:
count(Term, Goal, Result) :- sum(1, Term, Goal, Result).
There are other issues relating to aggregates to be considered
such as whether solutions should be ground.
------------------------------
Date: 19 Oct 87 15:41 -0700
From: Paul Voda <voda%ubc.csnet@RELAY.CS.NET>
Subject: Where is the meaning?
The discussion of style and methodology of Prolog programming in the
recent issues of Prolog Digest is quite interesting even though it is
mostly a rather lengthy monologue. Important as the style is, let me
ask a fundamental question:
Where is the meaning?
Take the SEND+MORE=MONEY example on page 161 of Bratko's text:
?- sum1([0,S,E,N,D],[0,M,O,R,E],[M,O,N,E,Y],
0,0,[0,1,2,3,4,5,6,7,8,9],_).
sum1([],[],[],0,0,Digs,Digs).
sum1([D1|N1],[D2|N2],[D,N],Ci,Co,Digsin,Digsout) :-
sum1(N1,N2,N,Ci,Cinterm,Digsin,Digs1),
digitsum(D1,D2,Cinterm,D,Co,Digs1,Digsout).
digitsum(D1,D2,Ci,D,Co,Digsin,Digsout) :-
del(D1,Digsin,Digs1),
del(D2,Digs1,Digs2),
del(D,Digs2,Digsout),
S is D1 + D2 + Ci,
D is S mod 10,
Co is S div 10.
del(A,L,L) :-
nonvar(A), !.
del(A,[A|L],L).
del(A,[B|L],[B|L1]) :-
del(A,L,L1).
The predicate del is given in Bratko on page 71 in the standard form
as follows:
del(A,[A|L],L).
del(A,[B|L],[B|L1]) :-
del(A,L,L1).
In this form the meaning of del is straightforward:
del(x,y,z) iff
the list z is exactly like the list y minus the element x
occurring in y.
If x does not occur in y then del(x,y,z) fails. The predicate del in the SEND
problem would seem to succeed in that case. Thus its meaning should be
as follows.
del(x,y,z) iff
the list z is exactly like the list y minus the element x if x occurs
in y, otherwise y = z.
But unfortunately this is not the case because
X = 3, del(X,[1,2],[1,2])
succeeds whereas
del(X,[1,2],[1,2]), X = 3
fails. The use of the 'nonvar' construct destroys the meaning of del.
An attempt to code del without the 'nonvar' as
del(A,L,L) :-
not member(A,L).
del(A,[A|L],L).
del(A,[B|L],[B|L1]) :-
del(A,L,L1).
does solve the problem of the meaning of del, but del cannot be used
as a generator of unused digits when A is not bound.
The beuaty of logic programming is that the meaning of a predicate
depends solely on the meaning predicates used in its definition
(even if the predicate is recursive). This is how meaning is defined
in predicate calculus.
The Bratko's use of del is operational. The "meaning" is obtained by
the sequence of calls to it: Keep on binding different digits to the
unbound variables. As a consequence, the meaning of predicates
'digitsum' and 'sum' cannot be derived from the meaning of 'del'
as it should be in logic. Both predicates achieve the desired goal
only because of clever sequencing of executed operations. The only
way to reason about the predicate sum1 is by the methods taking into account
the operational side, for instance by Hoare's pre- and post-conditions.
If we are reduced to such a reasoning we do not program in a logic programming
language but rather in a backtracking Pascal.
The standard "explanation" of constructs like var is that they are
meta-theoretical: rather than to contribute to the meaning, they control the
theorem prover. The use of the nonvar in the SEND problem does indeed
operationally control the executing mechanism, but whatever the executing
mechanism is, it is not a theorem prover. The mechanism operates above
any meaning. Thus it is meta-theoretical in the very meaning of the word
'meta' of being above any theory.
The proper way of solving the SEND problem is to generate the values of
D1 and D2 in the digitsum by a predicate 'digit', compute the result digit D,
and insert a call to 'alldiff' at the end of recursion.
This method is logical but albeit slower than a Pascal-like
operational solution.
Or alternatively, one could use the delaying of predicates or constraints
if these are available. There is yet another aspect of a logical
solution to the SEND problem along the outlined lines.
It is declarative all-right, but its declarativeness is quite low level
in the sense of specifying the meaning by the predicate 'digitssum' for all
columns of the problem.
Here is the solution to the problem in the constraint based language TRILOGY
(formerly R-Maple), L is the type of 32 bit integers:
pred Send(send::L,more::L,money::L) iff
a::[0..7]->>L[0..9] & a = [s,e,n,d,m,o,r,y] &
{the above line constraints all digts to be different}
send + more = money &
m <> 0 & s <> 0 &
send = 1000*s + 100*e + 10*n + d &
more = 1000*m + 100*o + 10*r + e &
money = 10000*m + 1000*o + 100*n + 10*e + y
-- Paul J. Voda
------------------------------
End of PROLOG Digest
********************
∂26-Oct-87 0522 MATHIS@C.ISI.EDU next meeting
Received: from C.ISI.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 05:21:58 PST
Date: 26 Oct 1987 05:21-PST
Sender: MATHIS@C.ISI.EDU
Subject: next meeting
From: MATHIS@C.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[C.ISI.EDU]26-Oct-87 05:21:15.MATHIS>
I hope you are all making your reservations for the next meeting,
Nov 16-18, in Colorado.
Messages about this were sent out to this list some time ago and
in the mail just recently.
Monday afternoon is for subcommittee meetings -- people who are
planning such should either respond to me directly or announce
them on this list.
Tuesday we will start about 9am.
Wednesday I would like to leave Denver about 7pm. That means the
meeting can run until 5pm. I expect that people will be staying
for the full afternoon. If a four o'clock ending time would
help, let me know so others can plan on it too.
As to the agenda -- I expect some discussion about windows on
Tuesday; some discussion about the Lisp1/Lisp2 issue; some
discussion about planning for the international work; more on
CLOS; and an extensive report from the clean-up committee (they
have been busy, but won't have their report mailed around in
advance). There are also other committees that will be
reporting.
If you have any suggestions for agenda organization, please let
me know. I will try to put out a more complete version by the
end of the week (if you get back to me).
Thanks, Bob
∂26-Oct-87 0736 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu The death of A.N. Kolmogorov.
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 07:35:55 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Mon 26 Oct 87 07:26:08-PST
Received: by lindy.stanford.edu; Mon, 26 Oct 87 07:27:53 PST
Received: by Forsythe.Stanford.EDU; Mon, 26 Oct 87 07:28:50 PST
Received: by NDSUVM1 (Mailer X1.24) id 2559; Mon, 26 Oct 87 09:21:51 CST
Date: 26 Oct 1987 10:18:13-EST (Monday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Leonid Levin <LND%BU-CS.BU.EDU@forsythe.stanford.edu>
Subject: The death of A.N. Kolmogorov.
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
I just learned that in Moscow died Andrei Nikolayevich Kolmogorov - a
great mathematician who also made crucial contributions to Theoretical
Computer Science, Probability and Statistics, Information Theory and
other fields. He also was one of those rare people whose personal
integrity influenced ethical and human standards to the extent possible
under the difficult conditions of a totalitarian state.
Any telegrams from organizations and persons who appreciated the
contributions of A.N. Kolmogorov will be gratefully received. They may
be directed to Moscow University, The Academy of Sciences of the
U.S.S.R. and the widow Anna Dmitriyevna Kolmogorov (117234, Moscow,
Moscow University, korpus (building) L, apartment 10, USSR).
∂26-Oct-87 0838 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU Oct 27 lunch
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 08:38:25 PST
Received: from Tenaya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 26 Oct 87 08:33:52-PST
Received: by Tenaya.Stanford.EDU (3.2/SMI-3.2)
id AA00155; Mon, 26 Oct 87 08:37:27 PST
Date: Mon, 26 Oct 87 08:37:27 PST
From: nilsson@Tenaya.Stanford.EDU (Nils Nilsson)
Message-Id: <8710261637.AA00155@Tenaya.Stanford.EDU>
To: faculty@score
Subject: Oct 27 lunch
Our Tuesday faculty lunch tomorrow will be at the CS Tressider
Academic Center (old bowling alley, LOTS II, look for sign at back
saying "CS TAC"). Discussion topic: The undergraduate CS program.
People might also give some thought to the question "Who should we
recommend to replace Gordon Bell at NSF?" (We haven't exactly been
asked by Bloch for advice on this matter, but Bell will be leaving
in a few months and I hear that Bloch would listen to good suggestions.)
-Nils
∂26-Oct-87 1143 GANGOLLI@Sushi.Stanford.EDU
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 11:42:59 PST
Date: Mon 26 Oct 87 11:29:56-PST
From: Anil R. Gangolli <GANGOLLI@Sushi.Stanford.EDU>
To: aflb.all@Sushi.Stanford.EDU
Office Phone: (415) 723-3605
Message-ID: <12345622516.34.GANGOLLI@Sushi.Stanford.EDU>
Here are the talks for the next two weeks, and another talk of possible
interest to AFLB participants.
THIS WEEK'S TALK:
29-October-87: Ramsey Haddad (Stanford University)
Cyclic $A↑i B C↑i$ Paths
in Labelled Graphs
(Joint work with Jeff Naughton, Princeton University.) This problem
arises in database queries: Given a graph with three types of edges,
A, B, and C, and given a node x_0, find all nodes y that are reachable
from x_0 by a path of the form A↑i B C↑i. Some O(ne) algorithms are
previously known for the case when either the A↑i or the C↑i portion
of the path is acyclic. We will show how to achieve O(ne) time for
the case when *both* the A↑i and C↑i portions are cyclic. This
involves the use of a conglomeration of numeric and graph ideas such
as: strongly connected components, the period of a graph,
intersections of semi-linear sets, and dynamic programming.
***** Time and place: Thurs, October 29, 12:30pm in MJH 352 (Bldg. 460) *****
NEXT WEEK'S TALK:
5-November-87: Tomas Feder (Stanford)
Optimal Algorithms
for Approximate Clustering
The clustering problem is that of partitioning a given set of n points
into k groups, called clusters, so that points within each cluster are
near each other. Two objective functions frequently used to measure
the performance of a clustering algorithm are (a) the maximum distance
between pairs of points in the same cluster, and (b) the maximum
distance between the points and "cluster centers"; we refer to the
chosen measure as the "cluster size".
We show that, while there is a polynomial time approximation scheme to
estimate the number of clusters that are needed for a fixed cluster
size, one cannot approximate the optimal cluster size for a fixed
number of clusters within a factor close to 2 in polynomial time,
unless P=NP. We present an algorithm which achieves this factor of 2
in time O(n log k), and show that this running time is optimal in the
algebraic decision tree model. Our approach can be extended to provide
optimal O(n log k) approximation algorithms for the related k-centers,
k-suppliers, and weighted k-suppliers problems.
This talk represents joint work with Daniel Greene at Xerox PARC.
***** Time and place: Thurs, November 5, 12:30pm in MJH 352 (Bldg. 460) *****
ANOTHER TALK OF AFLB INTEREST:
6-November-1987: Ashok Subramanian (Stanford)
Scatter-free Network Stability Problems
We introduce the notion of Network Stability Problems. A network is a
directed graph with a gate at each internal vertex, and with boolean inputs
and outputs. (A gate assigns to each output edge a boolean function of the
values on its input edges.) A network can have cycles. A stable
configuration of a network is an assignment of values to the edges of the
network in a manner consistent with the inputs and with the gate equations.
Network stability problems are questions about the stable configurations of
a network, e.g., are there any?, how do we find one fast?, how many are
there?, and so on.
We study network stability problems as a function of the set of gates
allowed. It is easy to show that the problem `Is there a stable
configuration?' is complete for NP if no restriction is placed on the set
of gates.
We introduce the notion of `scatter'. A restriction of a gate is a gate
obtained by assigning specific values to some (perhaps none) of the inputs,
and then discarding irrelevant inputs and outputs, i.e., inputs that
influence no outputs, and outputs that are fixed. A gate has scatter if it
has a restriction with more outputs than inputs. There is a simple
linear-time algorithm for finding a stable configuration of a network if
every gate lacks scatter.
Finally, we show how these ideas lead to a simple linear-time algorithm for
the stable roommates problem. The stable roommates problem is this: there
are $2n$ persons in a world with $n$ two-bedroom apartments; the task is to
decide who rooms with whom. Each person ranks all the other persons in
order of preference. An assignment is unstable if there are two people who
prefer each other to their current roommates. [This problem already has a
linear-time solution; we think ours is simpler.]
***** Time and place: Fri, November 6, 1:15pm in MJH 352 (Bldg. 460) *****
-------
∂26-Oct-87 1233 MATHIS@C.ISI.EDU Wednesday afternoon agenda
Received: from C.ISI.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 12:33:31 PST
Date: 26 Oct 1987 12:32-PST
Sender: MATHIS@C.ISI.EDU
Subject: Wednesday afternoon agenda
From: MATHIS@C.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[C.ISI.EDU]26-Oct-87 12:32:47.MATHIS>
I have already gotten an indication from a few people that they
have to leave around 2pm or 3pm Wednesday afternoon. That's
fine. However, it might make sense to have the last item on the
Wednesday agenda be something that might be considered less
central to the overall work. Any suggestions?
Thanks, Bob
∂26-Oct-87 1450 @Sushi.Stanford.EDU:hochbaum%newton.Berkeley.EDU@BERKELEY.EDU Feder's talk
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 14:50:05 PST
Received: from newton.Berkeley.EDU by Sushi.Stanford.EDU with TCP; Mon 26 Oct 87 14:42:46-PST
Received: by newton.Berkeley.EDU (5.57/1.16)
id AA06599; Mon, 26 Oct 87 14:40:46 PST
Date: Mon, 26 Oct 87 14:40:46 PST
From: hochbaum%newton.Berkeley.EDU@berkeley.edu (D.S. Hochbaum)
Message-Id: <8710262240.AA06599@newton.Berkeley.EDU>
To: GANGOLLI@sushi.stanford.edu, aflb.all@sushi.stanford.edu
Subject: Feder's talk
∂26-Oct-87 1552 TAJNAI@Score.Stanford.EDU US West Announcement of Opportunity
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 15:52:44 PST
Date: Mon 26 Oct 87 15:45:42-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: US West Announcement of Opportunity
To: faculty@Score.Stanford.EDU
Message-ID: <12345669077.16.TAJNAI@Score.Stanford.EDU>
"In continuation of the Sponsored Research program initiated by
U S WEST Advanced Technologies in December, 1986, we enclose
our Announcement of Opportunity, inviting the submission of
Intents to Propose.
The program is directed at generating new ideas and concepts that
will shape the future of telecommunications and information system
technologies. The fields of research taht we are supporting are
listed in the enclosed brochure. The brochure also provides information
and guidelines for entering the program, including proposal
requirements and a schedule of deadlines.
We look forward to receiving Intents to Propose in mid-November, and
for opportunities to collaborate with you."
Amount of money: $50,000 to $200,000
Areas: Systems engineering
Software Development
Advanced User Interfaces
Artificial Intelligence
Modeling & Simulation
Input/Output Technology
Architecture & Standards
Switching Technology
Transmission Transport Technology
Advanced Hardware
Mr. House only sent me one brochure. If you are interested, please
send me a message and I'll send you a copy. Deadline is Nov. 16 for
Submission of Intent to Propose. January 15 deadline for full proposal.
Carolyn
-------
∂26-Oct-87 1616 @Sushi.Stanford.EDU:dorit@ernie.Berkeley.EDU tomas Feder's talk
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 16:16:42 PST
Received: from ernie.Berkeley.EDU by Sushi.Stanford.EDU with TCP; Mon 26 Oct 87 16:03:01-PST
Received: by ernie.Berkeley.EDU (5.58/1.23)
id AA09175; Mon, 26 Oct 87 15:29:07 PST
Date: Mon, 26 Oct 87 15:29:07 PST
From: dorit@ernie.Berkeley.EDU (Dorit Hochbaum)
Message-Id: <8710262329.AA09175@ernie.Berkeley.EDU>
To: GANGOLLI@sushi.stanford.edu, aflb.all@sushi.stanford.edu
Subject: tomas Feder's talk
Will you please ask Tomas Feder to contact me. The content of
his next week presentation seems quite similar to work I have
done with D. Shmoys that have been published. I like to
speak to him about that and tell him about those references,
as well as try to understand how he could get the running times
he is reporting. thanks.
Professor Dorit Hochbaum
UC Berkeley.
∂27-Oct-87 0342 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #78
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 87 03:42:10 PST
Date: Sun 25 Oct 1987 10:48-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #78
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Tuesday, 27 Oct 1987 Volume 5 : Issue 78
Today's Topics:
Query - Negation as Failure,
Implementation - Prolog Machines,
LP Library - Rodger's Review
----------------------------------------------------------------------
Date: 22 Oct 87 08:43:54 GMT
From: reeves@locus.ucla.edu
Subject: forall/2 and negation as failure
I'm having a problem reading forall/2 and wondered if anyone could help.
In Sterling and Shapiro p. 270-271, the claim is that
forall(Goal,Condition) is true for all solutions of Goal, Condition is
true. Under this reading not(Goal, not(Condition)) works fine as far as I
can tell.
They claim that
forall(father(X,C),male(C))
is checking _for_ fathers that have all male children. My reading is that
it is checking _that_ all fathers have all male children. Their
implementation returns two solutions for the query: the fathers that have
only male children. In the database, however, there are fathers who do
not have only male children, so (I would think) the query should fail.
Is there a reading for forall/2 for the following implementation (from S&S)?
forall(G,C) :- setof(C,G,Cases), check(Cases).
check([Case|Cases]) :- Case, check(Cases).
check([]).
Alternatively, is there a case where:
forall(G,C) :- not(G, not C).
behaves counterintuitively, due to the use of not as negation-as-failure?
-- John Reeves
------------------------------
Date: 23 Oct 87 07:13:08 GMT
From: mcvax!unido!ecrcvax!jclaude@uunet.uu.net (Jean Claude Syre)
Subject: Prolog Machines
PROLOG MACHINES:
Here we go: below is a (non-exhaustive) list of machines/prototypes/
developments/basic research under way in different places around the
world, extracted from my presentation at a Panel on Parallel Inference
Machines at IJCAI87, Milano.
At ECRC, the Computer Architecture Group (17 people) is working
quite a lot on Sequential machines, but is also implementing a
Parallel Logic Programming System called PEPSys, on a commercial
multiprocessor. For more info contact us at ECRC Arabellastr. 17
D-8000 Munich 81 , BRD. We also would be pleased to get more info
on your activities (papers, reports, performance studies, ...) if
they deal with these topics, THANKS.
WORD is Word Length, KLIPS means the peak performance on Concat or
Naive reverse. The Klips is the most fuzzy unit to measure
performance of Prolog Systems (between 1 and 2000 assembly
instruction of a CISC computer, imagine..., but my opinion is that
REAL performance can be estimated at half of the peak performance for
Hardware implementations of Prolog, wheras it could be around 1/6th
to 1/10th of the peak performance for Software implementations).
NAME WORD KLIPS BY REMARKS
PSI I 40 25 Icot Inter., stand alone
PEK 34 40 U. KOBE
PSI I 40 110 Icot Compiled WAM
PLM 32 400 U. Berkeley WAM
CHI 36 250 NEC C&C ECL, WAM
CHI II ? 500? NEC ? (info wanted!)
IPP 32 1000 Hitachi ECL, WAM
PSI II 40 250 Icot stand alone wks,WAM
X1 32 300 Xenologic PLM, SUN co-proc.
ICM3 32 530 ECRC WAM, co-proc.
ICM4 32 680? ECRC RISC, fast memory
KCM 64 650 ECRC WAM, attached proc
DLM 38 600? BAe exp. board
AI32 40 200? Hitachi co-proc. chip
Pegasus 40 240 Mitsubishi RISC chip
SM45000 40 ??? Inference AI co-proc
MDS ?? 200?? Matra chip set
TOSHIBA ? ? 650 Attached Processor
OTHERS? CERTAINLY. I APOLOGIZE
Current work at ECRC:
KCM: Knowledge Crunching Machine (with Siemens, BULL, ICL): 64-bit,
tagged architecture. Private memory, two large Data and Code caches
Full Prolog/Lisp system, with extras.
------------------------------
Date: Sun, 18 Oct 87 22:05:27 PDT
From: quintus!ok@Sun.COM (Richard A. O'Keefe)
Subject: Rogers' textbook.
Having suggested in my previous message to this Digest that it
would be a good idea to discuss textbooks, here's some provocation.
I'm going to comment on a textbook:
@Book(RogersPrimer
, Key = Rogers
, Author = "Rogers, Jean B."
, Title = "A Prolog Primer"
, Publisher = Addison-Wesley
, Year = 1986
)
It is essential to point out before I start that Rogers explicitly
says "The audience for whom this book was written includes mature
learners who are neither experienced in computer programming nor
particularly sophisticated in mathematics." Rogers does claim that
"This book is also an effective introduction to Prolog for people
already quite familiar with computer programming", but obviously the
requirements of the first audience are the main control. I am quite
unable to judge the suitability of this or any other textbook for that
audience. The book "has been used for instruction in courses with
computer science and other graduate students, computer science under-
graduates, and undergraduates from non-computer-science majors. Their
feedback was a guiding factor in revisions for the book". It is worth
noting that Clocksin & Mellish can make precisely the same statement.
I should explain that I have not chosen to comment on Rogers' book
as an example of a notably bad book. Several people here liked it well
enough to buy copies. I am not commenting on the book as a whole in
any way at all. There are just two specific points I want to raise.
You should not attempt to guess my opinion of other aspects of the
book. For the most part, I have none.
The two points I want to discuss are setof/bagof and data base
design.
SETOF/BAGOF
Rogers explicitly states that "one version of Prolog is used
consistently in the examples and the explanations. That version is
Standard DECsystem-10/20 Prolog". We are entitled, therefore, to
conclude that when the book describes setof and bagof,
(a) Rogers has read the DEC-10 Prolog manual
(b) Rogers' book is intended to be true about DEC-10 Prolog
WHAT THE DEC-10 PROLOG MANUAL SAYS
setof(X, P, S)
Read this as "S is the set of all instances of X such that P is
provable, where that set is non-empty". The term P specifies a
goal or goals as in call(P). S is a set of terms represented
as a list of those terms, without duplicates, in the standard
order for terms. If there are no instances of X such that P is
satisfied, then the predicate fails.
The variables in appearing in the term X should not appear
anywhere else in the clause except within the term P.
Obviously, the set to be enumerated should be finite, and
should be enumerable by Prolog in finite time. It is possible
for the provable instances to contain variables, but in this
case the list S will only provide an imperfect representation
of what is in reality an infinite set.
If there are uninstantiated variables in P which do not also
appear in X, then a call to this evaluable predicate may
backtrack, generating alternative values for S corresponding to
different instantiations of the free variables of P. (It is to
cater for such usage that the set S is constrained to be
non-empty.) For example, the call:
| ?- setof(X, X likes Y, S).
might produce two alternative solutions via backtracking:
Y = beer, S = [dick,harry,tom] ;
Y = cider, S = [bill, jan, tom]
-- This was written in English, where "cider" denotes an
-- alcoholic beverage made from fermented apple juice. RAO'K.
The call:
| ?- setof((Y,S), setof(X, X likes Y, S), SS).
would then produce:
SS = [(beer,[dick,harry,tom]),(cider,[bill,jan,tom])]
Variables occurring in P will not be treated as free if they
are explicitly bound within P by an existential quantifier. An
existential quantification is written:
Y↑Q
meaning that "there exists a Y such that Q is true", where Y is
some Prolog variable. For example:
| ?- setof(X, Y↑(X likes Y), S).
would produce the single result:
S = [bill,dick,harry,jan,tom]
in contrast to the earlier example.
bagof(X,P,Bag)
This is exactly the same as setof except that the list (or
alternative lists) returned will not be ordered, and may
contain duplicates. The effect of this relaxation is to save
considerable time and space in execution.
X↑P
The interpreter recognises this as meaning "there exists an X
such that P is true". and treats it as equivalent to call(P).
The use of this explicit existential quantifier outside the
setof and bagof constructs is superfluous, and therefore is not
recognised by the compiler.
-- But it still WORKS in compiled code. RAO'K.
WHAT ROGERS SAYS
PP 134-135 (Using Built-in Predicates)
Two predicates that gather instances of occurrences of objects
are bagof and setof. To use these predicates, we specify a
goal and a variable in the goal. The predicates search through
the data base to find all appearances of the goal that can be
proved true. For each true goal, the constant value that was
instantiated to the specified variable is gathered into the
bag. The bag (a list) is instantiated to the variable given in
the third argument of the predicate. If there are no
occurrences, the goal fails. This data base and query using
the bagof predicate show how to collect a list of constants
designated by the variable.
parent(jan, bet).
parent(jan, cat).
parent(joe, ann).
parent(joe, cat).
?- bagof(Child, parent(jan,Child), B).
B = [bet,cat]
yes
If there is more than one possible list of instances because of
another variable in the specified goal, the goal can backtrack
and find other responses. For example, given
parent(jan, bet).
parent(jan, cat).
parent(joe, ann).
parent(joe, cat).
?- bagof(Child, parent(Who,Child), B).
Who = jan, B = [bet,cat] ;
Who = joe, B = [ann,cat] ;
no
The instantiation of different bags can be gathered into a
single response by using what is called an existential
quantifier on the non-gathered variables from the goal. The
variable name followed by a caret (↑) appears just before the
predicate. A predicate with several variables requires a
sequence (e.g., A↑B↑C↑D↑).
Using the data base above
?- bagof(Child, Who↑(parent(Who,Child)), B).
B = [bet,cat,ann,cat],
Who = _45,
Child = _24 ;
no
This existential quantifier (read X↑ as "there is an X such
that") is used only in bagof and setof.
The setof predicate works as though bagof is called to gather
the values into a list before the list is sorted. As in the
result of sort, any duplicates will have been removed.
Using the data base above
?- setof(Child, P↑(parent(P,Child)), S).
S = [ann,bet,cat],
P = _45,
Child = _24 ;
no
P 203 (Appendix: Built-in Predicates)
bagof(V,P,B)
This predicate gathers all the instances of the variable V
that appear in goals, P, that are provable. It puts the
instances into a list that is instantiated to the bag B.
If there are no instances, the goal fails.
setof(X,P,S)
This predicate works as though bagof had been followed by
sort. That is, the elements in the list, S, are sorted and
duplicates have been removed. Existential quantifiers can
be used with bagof and setof. For example,
bagof(X, A↑B↑C↑one(A,B,C,X), B).
COMMENTS.
It's been a while since I read the setof/bagof section in the
DEC-10 Prolog manual critically. I am pleasantly surprised at how
precisely it manages to say just what is true. It even manages to
convey the impression that setof/3 is the fundamental predicate and
bagof/3 is secondary, which is epistemologically true even if it may
not be true of an *implementation* of the operations. Rogers, alas,
manages to convey the opposite impression.
PROBLEM ONE:
The really vital predicate for an implementor to provide and
for a programmer to understand is setof/3. setof/3 was added
to the DEC-10 Prolog language to make certain types of data-
base query expressible in Prolog. bagof/3 is just a hack you
can use when you know that the exact representation of the set
doesn't matter too much. Rogers manages to suggest that the
way to understand setof/3 is to understand one way it might be
implemented.
A much worse problem is the foggy language. Instantiation is a
process in which variables in a term TA are bound to other terms,
forming a new term TC. TC is said to be an instance of TA, and TA is
said to be instantiated to TC. <<Terms>> are <<instantiated>>,
<<variables>> are <<bound>>. Since a variable is a special case of a
term, it is accurate to speak of instantiating a variable to a term.
But you cannot instantiate a constant to something, it hasn't got any
variables to bind. If the variable X is bound to 47, it is true that X
is instantiated to 47, but it is not true that 47 is instantiated to X.
Rogers could perhaps employ the Humpty-Dumpty offence, but the nearest
thing to a definition of "instantiation" in the book is on p55, and as
that clearly talks about a <<variable>> being instantiated or
uninstantiated, the standard direction must be assumed.
The same distinction applies in conventional languages, where an
assignment statement X := 47 is read as "47 is assigned to X" or "X is
assigned the value 47". But X is not assigned to 47! It's as
different as you paying tax to the IRS or them paying tax to you.
It is *especially* important to keep one's language straight when
teaching beginners, because they don't know enough to correct their
teacher, and a teacher with confused language is likely to have
confused students.
I found Rogers' language in these two passages very confusing. For
example, what is "an instance of an occurrence of an object"? Neither
"object" nor "occurrence" is in the index. Neither is "appearance of a
goal" defined that I can see. The book does not say what it means for
a "list of constants" or anything else to be "designated by a
variable"; "designated" is not in the index.
PROBLEM TWO:
The language in these passages looks like technical language
but is not being used with the precision proper to technical
language. A key technical word is being used backwards! The
effect is very confusing.
You may dismiss this as "nit-picking". Well, there are two answers
to that. With all the earnestness I possess, I tell you that I found
Rogers' explanation of setof/3 and bagof/3 so confusing that if I had
been trying to learn Prolog from this book I would have given up trying
to understand setof/3 and bagof/3, and would have started to have
serious doubts about Prolog generally. Without any earnestness at all,
I would point out that "nit" is one of the oldest words in the English
language. It comes from the Indo-European stem "knid-" (so is at least
5,000 years old) and means the egg of a louse. Picking nits out of the
hair is an essential part of health care, if there are any nits. Could
any of you seriously suggest that heads should have lousy hair on them,
or lousy ideas in them?
Let's suppose that one works one's way past the fog. In a book for
beginners, it is difficult to tell the whole truth. One's readers may
not possess the vocabulary needed to express the whole truth. But
everything one says should be true. It is quite proper to simplify,
but it is important to say that one has done so.
PROBLEM THREE
The following statements are reasonable inferences from
what Rogers says, but are not true.
In bagof(V, G, L) or setof(V, G, L)
(a) V must be a variable.
(b) V must occur in G.
(c) L must be a variable.
(d) G must bind V to constants.
(e) G will be solved by checking the data base,
not by general interpretation.
Re point (e), I would remind you that Rogers explicitly says that
"The predicates SEARCH THROUGH THE DATA BASE TO FIND ALL APPEARANCES".
It is probably a coincidence that points (a), (b), (c), and (d) were
also exhibited by Lagache in his library documentation. Since Rogers
must have had access to the DEC-10 Prolog manual, at least the
falsehood of (a) should have been apparent to her.
Am I nit-picking again? Not at all. It is USEFUL that (a) is
false. The DEC-10 Prolog manual even includes an example. When
converting between one representation of a graph and another, I have
very often found it useful to do
setof(Node-Neighbours,
setof(Neighbour, adjacent(Node,Neighbour), Neighbours),
Graph)
As for point (b), I have found it useful too, but at a minimum it is
useful to know that the Prolog system does not regard it as an error
for there to be no variable common to V and G, so that if that should
that be the cause of a bug in your program, you will know that Prolog
can't be expected to tell you about it.
[ Begin digression.
Having a call to setof/3 or bagof/3 where the first argument
is ground or contains a variable not in the second argument
is sufficiently odd that it is worth checking. You might like
to add this to your library:
checked_setof(Template, Generator, Set) :-
check_sb(Template, Generator, Set, set_of),
setof(Template, Generator, Set).
checked_bagof(Template, Generator, Bag) :-
check_sb(Template, Generator, Bag, bag_of),
bagof(Template, Generator, Bag).
check_sb(T, G, _, _) :-
\+ numbervars(T, 0, 0), % T not ground
\+ ( numbervars(G, 0, N),
( N = 0 % G not ground
; numbervars(T, N, X),
X > N % T not covered
)
),
!.
check_sb(T, G, L, P) :-
/* I don't care about efficiency here */
Query =.. [P,T,G,L],
format(user_error,
'~N! Bad template or generator~n! Goal: ~q~n',
[Query]),
format(user_error,
'Enter true, fail, or abort. ', []),
read(user_input, Command),
call(Command).
This code has been tested in Quintus Prolog.
If you think this kind of mistake is one you are likely to make,
it would be worth your while using an interface like this. The
cost of checking is comparable to the cost of finding one more
solution.
End digression.
]
Concerning point (d), the same example in the DEC-10 Prolog manual
that refutes point (a) refutes point (d). It is useful to be able to
collect proof trees, or picture descriptions, or fragments of code, or
whatever. If p(X) is a query which instantiates X to constants, then
X↑(p(X), name(X,Chars)) is a query which unifies Chars with a list of
character codes, and it is reasonable to write
setof(Chars, X↑(p(X), name(X,Chars)), SetOfNames)
[ Begin digression.
In fact it is more efficient not to do that. The trouble is
that executing an all-solutions predicate like findall/3, or
bagof/3, or setof/3, involves copying all the instances you
want, so the smaller the instances the cheaper. It is also
cheaper to compare smaller terms. So a more efficient way of
writing the query above is
setof(X, p(X), SetOfConstants),
maplist(name, SetOfConstants, SetOfNames)
The original version of the query is a perfectly sensible thing
to write, and the time to worry about efficiency like this is
AFTER that part of the program is working. Even when parts of
the result can be recomputed, as here, it may be more efficient
to copy the results rather than recompute them. It all depends
on the problem. Feel free to make the first argument of an all-
solutions predicate precisely as complex as suits the problem,
but try not to make it any bigger.
There is a general point here about when you should move a
computation inside setof/3 and when it should be outside.
Let's leave that for another time; it belongs in a general
discussion of sequence mapping. But if the computation is
likely to fail, or to produce smaller results, putting it
inside may be a good idea. Watch out for free variables!
End of digression.
]
There is a lot more I could say. But that's probably enough. It
may seem unfair to you that I have said so much about so very little of
Rogers' book. After all, this is a primer. Well, I repeat that I am
not giving a general review of Rogers' book. (This is fun, but it is
time-consuming.) Other parts of it may be excellent. All I am saying
is that
The sections of Rogers' book which describe setof/3 and bagof/3
are confusing to read and may lead reasonable readers to believe
things about those predicates which are not true.
It may, for all I know, be an excellent book in other respects. I
repeat that I do not regard myself as competent to judge what is a good
book for complete beginners and what is not.
If any of you is considering writing a Prolog textbook, I would
urge you to give setof/3, bagof/3, and findall/3 a chapter to
themselves, with lots of examples, chosen so that the all-solutions
predicates are naturally wanted to solve the problems, not contrived
"X likes Y" or "parent(X,Y)" examples invented to illustrate the
solutions.
That's finished with setof/3 and bagof/3. But there is another
point in Rogers' book which is worth discussing. I'm not referring to
page 174, which is likely to leave the reader believing that
"module"="predicate". If I were going to refer to that, I'd have to
refer to exercise 10.3.2, and I can't see any *point* in rewriting that
clause at all, let alone into three modules. (Whatever they are.
"Module" is not in the index. Looking at the answer, it appears that
"module"="clause". Not in Quintus Prolog, Prolog-X, or NIP it isn't.]
The second point concerns data base design, which is not something
that Rogers claims to cover, so this should not be read as a criticism
of things Rogers does claim to cover. The example actually comes from
the chapter on arithmetic.
Rogers says
Suppose we have a Prolog data base that contains information
about the presidents of the United States in the form:
president(<name>, <birthyear>,
<year began office>, <year left office>).
From this base, we can derive several kinds of information.
How long was a president in office:
length_of_office(Name, Years) :-
president(Name, _, In, Out),
Years is Out-In.
How old was a president when he took office:
age(Name, Years) :-
president(Name, Birth, In, _),
Years is In-Birth.
And so on. What is wrong with this?
There is a problem endemic among all sorts of textbooks. I first
had it brought to my attention in Statistics textbooks. The problem is
this:
- authors write examples to illustrate methods.
So they work from a known method to an invented example.
- students are trying to acquire two kinds of knowledge:
- how the methods work
The examples are usually adequate for this
- WHEN TO USE a particular method
And it is not uncommon for the methods to be
inappropriate to the invented problems.
That is, very often there is a better way to handle a given example
than the method the example has been chosen to illustrate, so a student
who is trying to work out when to use the method is left confused.
I wouldn't be surprised to find the same problem showing up in
carpentry textbooks.
The specific problem here is that Rogers is illustrating
arithmetic, and the examples she has made up do in fact illustrate the
aspects of arithmetic she is trying to explain. BUT any interested
student is going to look at section 9.4 as an example of how to put
together a data base about American presidents AS WELL. Indeed, as we
have seen with quicksort, it is not uncommon for students to miss the
real point of an example entirely and focus exclusively on the example
as a way of solving the invented problem.
What's wrong with this design of the data base? Briefly, the
information should be held in two predicates, not one:
birth_year(Name, Year)
presidency(Name, BeginningYear, EndingYear)
Indeed, there is a strong argument for splitting the second of these
predicates into two predicates itself: for how are we to say anything
about the *present* president?
I am not a citizen of the United States. I have heard that a
president can serve for only two consecutive terms, but I do not know
whether a president can serve two separated terms, or more than two
separated terms. I know that originally when a president died in
office the vice-president assumed his duties but not his title, but that
now he assumes the title as well, but I don't know whether that affects
the permitted number or consecutivity of terms. I can see no a priori
reason why a president might not resign part way through one term and
then return to office 10 years later. There is certainly nothing to
prevent Prime Ministers in many countries from holding office in
separated terms.
So in principle, it looks as though there could be two clauses
for some presidents. Let's imagine a hypothetical case:
president(ryan, 1660, 1700, 1704).
president(ryan, 1660, 1708, 1712).
Now let's pretend that we discover that we got the year of birth wrong
(not an implausible assumption), and want to change it. Now we have to
change TWO places.
****************
* A general rule of thumb for data base design is that each piece
* of information should be represented in ONE place. The uniqueness
* of this place should not depend on the contents of the data base
* but should be built into the structure.
****************
Now let's consider it from another angle. Suppose we have
president(macfarland, 1680, 1712, 1716)
and someone tells us no, it was 1716-1720. We have to remember to copy
the BirthYear from the old president/4 fact to the new one.
****************
* Another general rule of thumb is that pieces of information which
* are likely to be updated independently should be in different places
****************
Suppose we decided to represent information about vice-presidents
as well. Following Rogers' example, we would have facts
vice_president(Name, BirthYear, In, Out).
An obvious question is, for any two people X Y in the data base, was X
born before Y or not? With this structure, we have to write four
cases: X is a president/vice_president, Y is a president/vice_president.
But with the structure which keeps the birth year separate, we can write
born_before(X, Y) :-
birth_year(X, Xyear),
birth_year(Y, Yyear),
Xyear < Yyear.
****************
* Another rule of thumb is that a conceptual relation should be
* represented by a single relation, not by different relations for
* different types
****************
That's a bit vague, and there are justifiable exceptions, but
having to look in different places for the birth dates of presidents
and vice-presidents would be silly. Rogers' does not have an example
doing this. All I claim is that a naive reader without the benefit of
Rogers' actual presence could be misled by the example in section 9.4
into doing this.
Almost any good data-base textbook will do a much better job of
explaining these potential problems than I'm likely to. Look in the
index under "update anomalies" and "normal forms". Read Kent's book
"Data and Reality". When you know what a "join dependency" is, you'll
know why you will usually want to design them out.
--------------------------------
CONCLUSION
I've discussed at length two problems with Rogers' book. Would
someone who thinks it is a good textbook say what they like about it
and why they think it is better than some other textbook? I repeat
that I am not saying that Rogers' book is specially bad. Prolog
textbooks which explain setof/3 and bagof/3 lucidly and accurately are
vanishingly rare, and the problem of examples seems to apply to most
textbooks. Do you think these aspects matter? Would anyone teaching a
Prolog course like to say what text(s) s/he is using, why, and what
supplementary material is needed?
Are there any good elementary books on data base design? Anyone
got a favourite they'd like to recommend?
------------------------------
End of PROLOG Digest
********************
∂27-Oct-87 1425 HADDAD@Sushi.Stanford.EDU BATS: Nov. 12 Bay Area Theory Seminar at Berkeley
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 87 14:25:24 PST
Date: Tue 27 Oct 87 14:18:55-PST
From: Ramsey Haddad <HADDAD@Sushi.Stanford.EDU>
Subject: BATS: Nov. 12 Bay Area Theory Seminar at Berkeley
To: aflb.su@Sushi.Stanford.EDU, su-events@Sushi.Stanford.EDU
Message-ID: <12345915421.50.HADDAD@Sushi.Stanford.EDU>
BATS, the Bay Area Theory Seminar, will be held at UC Berkeley on
Thursday, November 12 in Sibley Auditorium in the Bechtel Engineering
Center.
The schedule is as follows:
10:10 Valerie King (Berkeley): An OMEGA(n↑(8/7)) Lower Bound on the
Randomized Complexity of Graph Properties
11:10 Cynthia Dwork (IBM): Interactive Proof Systems with a Weak Verifier.
12:10 Lunch
1:10 Michael Kearns (Harvard, Santa Cruz): Learning From Examples:
Lower Bounds and Malicious Errors
2:10 Anton T. Dahbura (AT&T Bell Laboratories): System-Level Diagnosis
for Multiprocessor Systems
*********************************************************************
An OMEGA(n↑(8 / 7)) Lower Bound on the Randomized Complexity
of Graph Properties
Given any input graph on n nodes, we must determine whether the
graph has a given property by asking questions of the form:"Is edge {i,j}
in the graph?" The decision tree algorithm may branch according to the
information already gained. Complexity is measured by the number of
queries required in the worst case.
A property is a "graph property" if it is invariant under renumbering
of its nodes. All graph properties which are monotone (not destroyed
by the addition of edges) and nontrivial (holds for some but not all
graphs) have complexity OMEGA(n↑2).
In this talk, we investigate the power of randomness by considering
randomized decision tree algorithms in which coins may be flipped to
determine the next query. The complexity of a randomized algorithm
is the expected number of queries in the worst case. The randomized
complexity of a property is the minimum complexity of any randomized
decision tree algorithm which computes the property. We improve Yao's
lower bound on the randomized complexity of any monotone nontrivial
graph property from OMEGA(n(log n)↑(1/12)) to OMEGA(n↑(8/7)).
*********************************************************************
Learning From Examples: Lower Bounds and Malicious Errors
In the first part of this talk, we give a general lower bound on the
number of examples needed to learn a class of functions in the sense
of Valiant (1984). This lower bound is based on a combinatorial
parameter known as the Vapnik-Chervonenkis dimension, and is within
a log factor of the general upper bound given in Blumer et. al. (1986).
We apply the lower bound to prove that many of the existing learning
algorithms (including those for bounded disjunctive normal form in
Valiant (1984) and decision lists in Rivest (1987)) use a number of
examples that is optimal or nearly optimal. Part one is joint
research of A. Ehrenfeucht, D. Haussler, M. Kearns and L. Valiant.
In the second part, we study an extension to the learning model in
which errors chosen by an adversary are present in the sample data.
After giving limitations on the rate of error tolerable by any learning
algorithm, we demonstrate classes for which the maximum error rate can
actually be achieved by efficient algorithms that use a number of
examples matching the lower bound for the error-free case. We conclude
by showing a strong relationship between the Set Cover problem and the
problem of learning monomials with errors: an heuristic for a generalization
of Set Cover, based on Chvatal (1979), is used to obtain an improved
error rate for monomials, and a reduction is given proving that approaching
the optimal error rate is at least as hard as finding improved approximation
algorithms for Set Cover. Part two is joint research of M. Kearns and M. Li.
This talk assumes no familiarity with the Valiant model of machine learning.
*********************************************************************
System-Level Diagnosis for Multiprocessor Systems
This talk gives an overview of twenty years of achieve-
ment in system-level diagnosis for multiprocessor systems,
emphasizing recent dramatic results concerning diagnosis and
diagnosability algorithms. Within this framework, the
speaker's own research and efforts towards more realistic
and useful fault detection and diagnosis strategies are
presented. Several open problems and conjectures are
described and areas for future research are suggested.
*********************************************************************
-------
∂27-Oct-87 1438 HADDAD@Sushi.Stanford.EDU BATS: lunches, parking permits, and rides
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 87 14:38:26 PST
Date: Tue 27 Oct 87 14:25:47-PST
From: Ramsey Haddad <HADDAD@Sushi.Stanford.EDU>
Subject: BATS: lunches, parking permits, and rides
To: aflb.su@Sushi.Stanford.EDU, su-events@Sushi.Stanford.EDU
Message-ID: <12345916671.50.HADDAD@Sushi.Stanford.EDU>
Any Stanford people going to BATS should let me know by Nov. 4 so that
I can give the Berkeley people an approximate count for lunch (which
they provide).
I also need to know who will need parking permits and I will
coordinate car pooling. Hence, let me know if you:
(1) Are driving on your own and need a permit.
(2) Are driving and willing to take X passengers. (What is X?)
(3) Would like a ride from someone.
Ramsey
-------
∂27-Oct-87 1559 TAJNAI@Score.Stanford.EDU call for Forum speakers
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 87 15:59:50 PST
Date: Tue 27 Oct 87 15:39:26-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: call for Forum speakers
To: faculty@Score.Stanford.EDU
cc: hiller@Score.Stanford.EDU
Message-ID: <12345930080.38.TAJNAI@Score.Stanford.EDU>
Reminder. Please send your student nominations to me by Monday
morning (Nov. 2). David Ungar, Program Chairman, and I must block
the program, notify the speakers, get their working titles, and
prepare the Preliminary Program for mailing mid December.
Carolyn
-------
∂28-Oct-87 0227 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #79
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Oct 87 02:27:37 PST
Date: Sun 25 Oct 1987 11:03-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #79
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Wednesday, 28 Oct 1987 Volume 5 : Issue 79
Today's Topics:
Query - Algorithmic Debugging,
Implementation - Style,
LP Library - Textbook Review
----------------------------------------------------------------------
Date: Tue, 20 Oct 87 21:09:36+0900
From: Dongwook Shin <dwshin%csd.kaist.ac.kr@RELAY.CS.NET>
Subject: Algorithmic debugging
BIM_Prolog is advertised to provide rich programming environments.
Especially, BIM_Prolog brochure says that it also include the
algorithmic debugging facility originally devised by Shapiro, without
precise description. Is there anyone out there who knows that this
algorithmic debugging is also applicable to impure Logic Programmings
( with "cut", "assert", and "retract")? Any information would be
appreciated. Thanks!
-- D.W. Shin
------------------------------
Date: 19 Oct 87 09:23:00 EST
From: <cugini@icst-ecf.arpa>
Reply-to: <cugini@icst-ecf.arpa>
Subject: programming style
We seem to have some people on the list who have strong ideas about
Prolog style. Here's something that comes up over and over again
in my code and if there's an accepted neat way to handle it, I'd
be happy to know.
The general problem is how to write reasonably efficient code which
smoothly accepts different variables as input or output.
For instance, suppose we have lots of ground facts like this:
parent_child( big_Lothar, little_Lothar).
with the obvious interpretation, and we want to construct an
ancestor_descendant predicate. The naive and clean version
might be:
ancestor_descendant(Anc, Des) :- parent_child(Anc, Des).
ancestor_descendant(Anc, Des) :-
parent_child(Anc, Middle),
ancestor_descendant(Middle, Des).
This is all just ducky if Anc is ground on invocation. However, if
we invoke this with Des as the "input" and especially if we want to
get multiple solutions, then of course the code gets inefficient
because it randomly (random wrt the intent) chooses someone as a
possible ancestor and then blindly tries to construct a path to Des.
If we have a couple of hundred ground facts, the inefficiency could
be prohibitive. After all, a possible Anc fails only after all
his/her descendants have been tried and found wanting (ie not = Des).
Of course we could do some variation of this:
ancestor_descendant(Anc, Des) :- parent_child(Anc, Des).
ancestor_descendant(Anc, Des) :-
nonvar(Anc) ->
(parent_child(Anc, Middle),
ancestor_descendant(Middle, Des)
);
(parent_child(Middle, Des),
ancestor_descendant(Anc, Middle)
).
but now we've used a non-logical test and have semi-duplicated code, etc.
Comments ?
-- John Cugini
------------------------------
Date: Tue, 20 Oct 87 23:09:43 PDT
From: quintus!ok@Sun.COM (Richard A. O'Keefe)
Subject: Another textbook
This one is
@Book(malpas-primer
, Key = Malpas
, Author = "Malpas, John"
, Title = "PROLOG: A Relational Language and its Applications"
, Publisher = Prentice-Hall
, Year = 1987
)
Once again, this is NOT a general review of the book.
There are several things about this book that I think are good,
such as the glossary. Let's briefly comment on that.
He calls compound terms "structures". The word "structure"
is indeed used in logic, but it certainly does not mean a
compound term. The word "structure" is indeed used in
old-fashioned programming, but it doesn't mean a compound term
there either. Instead it means a record, and records have
mutable Fields which are accessed by symbolic name. Compound
terms have immutable Arguments which are accessed by position.
Why use a word which manages to mislead both programmers and
logicians when there is a precise term ready to hand which has
no false connotations?
Yet again, he says that "| is known as the list constructor".
I hope it isn't known as that, because "|" is NOT the list
constructor in most of the Prolog systems Malpas says his book
is relevant to, particularly not in C Prolog, which is the basic
system he worked from. The list constructor is '.', and in
DEC-10 Prolog, C Prolog, and Quintus Prolog, you can say
| ?- op(600, xfy, .).
to make expressions such as
X = a.b.[]
legal. And even if you don't,
| ?- functor([a,b], ListConstructor, 2).
binds ListConstructor = '.'
in those Prologs.
Is this nit-picking? Well, no. Read Ayn Rand's "An Introduction to
Objectivist Epistemology". It is impossible to think clearly about a
topic if your vocabulary about that topic is muddled. Anyone who
believes that "|" is the list constructor is in for a nasty shock when
| ?- functor(List, '|', 2).
fails to construct a list.
Is this NIH syndrome? Well, no. I have several times suggested to
the BSI Prolog group that they should canonise the terminology in John
Lloyd's book, filling in anything else from Robinson's "Logic Form and
Function" or failing that Common Lisp. (The BSI Prolog group are
inventing a new language, so compatibility appears not to be of interest
to them.) If you notice me using poor terminology, please let me know,
and I'll mend my ways. I know that I tend to be rather slipshod about
predicate -vs- procedure, and it's not good enough!
Another good feature of the book is its catalogue of Prolog
implementations. It is one of the few books about real Prolog to tell
you about Turbo Prolog.
There are other good things I could say about this book. So let's
get on with the criticism.
My touchstone for evaluating the quality of a Prolog textbook is to
see what it says about all-solutions predicates. (Don't forget that
part of the point of these two textbook reports is to justify my claim
that Lagache's difficulties with findall&Co are no worse than some
textbooks.)
setof/3 and bagof/3 are not in the index of this book. findall/3,
however, is. Page 338 provide what is described as "source code for a
version of findall". Here is the code.
findall(Element, Query, _) :-
Query,
gettmplist(List),
append(List, [Element], Newlist),
assert(tmplist(Newlist)),
fail.
findall(_, _, List) :-
retract(tmplist(List)),
!.
gettmplist([]) :-
\+ tmplist(_),
!.
gettmplist(List) :-
retract(tmplist(List)),
!.
unique_value_list(Element, Query, _) :-
Query,
gettmplist(List),
( member(Element, List),
assert(tmplist(List))
; \+ member(Element, List),
assert(tmplist([Element|List]))
),
fail.
unique_value_list(_, _, List) :-
retract(tmplist(List)),
!.
Ouch!
It is interesting that this is the only version of findall/3 I have
ever come across which fails when there are no solutions. Suppose that
the dynamic predicate tmplist/1 is initially empty. Then we trace
?- findall(*, fail, List)
Clause 1 calls fail, which fails.
Clause 2 calls retract(tmplist(List)), which fails.
findall/3 fails.
The correction for this, of course, would be to change the last clause
of findall/3 to
findall(_, _, List) :-
gettmplist(List).
and make the corresponding change to unique_value_list/3. Of course,
this version of findall/3 is not steadfast. If you call
?- findall(*, true, [X,Y]).
the second clause of findall/3 will fail, because
retract(tmplist([X,Y]))
will <<correctly>> fail to recognise the clause
tmplist([*])
findall/3 having failed, tmplist([*]) will be left in the data base.
So if we then call findall/3 again in utter disbelief, we'll get the
incorrect answer X = *, Y = *. Try it! The correction for this would
be to make gettmplist/1 steadfast.
gettmplist(List) :-
retract(tmplist(L)),
!,
List = L.
gettmplist([]).
Having fixed two bugs, we are then left with the problem that this
version of findall/3 will not work if calls to findall/3 can be nested.
As indeed they can and should be. This is not the only textbook with
an all-solutions predicate which cannot be nested. I do not understand
this. Why would anyone fail to worry about nested calls to control
structures? Well, we can hack around this bug by temporarily moving
the outer value out of the way.
findall(Template, Generator, List) :-
retract(tmplist(OuterList)),
!,
findall_1(Template, Generator, L),
assert(tmplist(OuterList)),
List = L.
findall(Template, Generator, List) :-
findall_1(Template, Generator, List).
findall_1(Template, Generator, List) :-
/* what findall/3 used to be */
That only leaves us with efficiency problems (I think. I haven't
really been able to stomach testing it.)
One source of inefficiency is the way the list is built up using
append/3. If the final list has N elements, we'll have done
about (1/2)N↑2 calls to append. This is in fact pretty much what
naive reverse does. If instead, the list were built up by adding
elements at the front and then reversing the final list, list
manipulation would take O(N) time.
The preferred way of building a list in Prolog is
to calculate L = [L1,...,Ln] do
calculate_list([], LoopVars) :-
ended(LoopVars).
calculate_list([Element|Elements], LoopVars) :-
calculate_next_element(LoopVars, Element),
advance_loop_variables(LoopVars, NextVars),
calculate_list(Elements, NextVars).
Where you can't do this,
calculate_list(List, InitVars) :-
calculate_list([], Rev, InitVars),
reverse(Rev, List).
calculate_list(L, L, LoopVars) :-
ended(LoopVars).
calculate_list(L0, L, LoopVars) :-
calculate_next_element(LoopVars, Element),
advance_loop_variables(LoopVars, NextVars),
calculate_list([Element|L0], L, NextVars).
In some implementations of Prolog, this may be enough to take the
cost down to O(|Size of answer List|) time. But not in any of the
Prolog implementations mentioned by Malpas. What is the reason for
that? If you have a List of size |List| in the data base, and an
Element of size |Element| you want to add to it,
| ?- retract(tmplist(List)),
!,
assert(tmplist([Element|List])).
will cost O(|List|+|Element|) space and time in a structure-sharing
system, and O(2*|List|+|Element|) space and time in a structure-
copying system. retract/1 in effect makes a copy of the clause it
deletes. In a structure-sharing system, this is pretty cheap, at
the price of delaying the reclamation until there are no further
references to any part of the deleting clause. In a structure-copying
system, it takes O(|List|) time and space to build the copy. Some
systems might do better if substantial parts of the clause are ground.
Then assert takes O(|List|+|Element|) time and space to build a copy
of the new term. This has to be done so that any variables in the term
will be properly handled. Again, if substantial parts of the new
clause are ground some systems may do better.
With all these copies going on, the cost of this version of findall/3
is O(length of final result*size of final result). Whew!
If you are going to maintain a stack or an output-restricted deque
in the data base, do it by using
asserta/1 to add items at the head of the deque
assertz/1 to add items at the foot of the deque
retract_first/1 to remove items from the head of the deque.
DON'T try to view the thing as a single "variable" held in a single
clause, because updating that "variable" will be appallingly costly in
nearly every Prolog system.
I don't know where Malpas got this code, or why he chose to
recommend it to his readers rather than the version in Clocksin &
Mellish. It is pretty bad.
Have any Prolog Digest readers any experience with this book,
either learning Prolog from it yourself, or trying to teach a class
with it? What do you think are the particularly good features of
the book? Do you think it matters that the code given in an
appendix for an operation already available in some form in most of
the Prolog systems he cares about is poor? Are there any examples
in the book which you think are particularly helpful?
Final repetition: this is not a general review of the book, and
there are good things in it too.
------------------------------
End of PROLOG Digest
********************
∂28-Oct-87 1553 TAJNAI@Score.Stanford.EDU Need Commencement Cap
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Oct 87 15:53:07 PST
Date: Wed 28 Oct 87 15:46:27-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Need Commencement Cap
To: faculty@Score.Stanford.EDU
Message-ID: <12346193500.38.TAJNAI@Score.Stanford.EDU>
I borrowed a robe from Arthur Keller, but he can't find his cap.
Does anyone have a cap I can borrow for Halowe'en?
Carolyn
-------
∂28-Oct-87 1732 EMMA@CSLI.Stanford.EDU CSLI Calendar, Oct. 29, 3:5
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Oct 87 17:32:39 PST
Date: Wed 28 Oct 87 16:39:29-PST
From: Emma Pease <Emma@CSLI.Stanford.EDU>
Subject: CSLI Calendar, Oct. 29, 3:5
To: friends@CSLI.Stanford.EDU
Tel: (415) 723-3561
Message-ID: <12346203156.21.EMMA@CSLI.Stanford.EDU>
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
29 October 1987 Stanford Vol. 3, No. 5
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 29 October 1987
12 noon TINLunch
Ventura Hall Reading: "Cognitive Significance and New Theories
Conference Room of Reference"
by John Perry
Discussion led by Bob Moore
(bmoore@sri.com)
Abstract below
2:15 p.m. CSLI Seminar
Room G-19 An Introduction to Situated Automata
Redwood Hall Part I: Basic Concepts
Stanley J. Rosenschein (Stan@warbucks.ai.sri.com)
Abstract in last week's Calendar
3:30 p.m. Tea
Ventura Hall
--------------
CSLI ACTIVITIES FOR NEXT THURSDAY, 5 November 1987
12 noon TINLunch
Ventura Hall Reading: "The Logicist Conception of Knowledge
Conference Room is too Narrow---But so is McDermott's"
by Stanley J. Rosenschein
Discussion led by the author
(Stan@warbucks.ai.sri.com)
No abstract
2:15 p.m. CSLI Seminar
Room G-19 An Introduction to Situated Automata
Redwood Hall Part II: Applications
Stanley J. Rosenschein (Stan@warbucks.ai.sri.com)
Abstract below
3:30 p.m. Tea
Ventura Hall
--------------
THIS WEEK'S TINLUNCH
Reading: "Cognitive Significance and the New Theories of Reference"
by John Perry
Discussion led by Bob Moore
October 29
In this paper, John Perry replies to Howard Wettstein's article "Has
Semantics Rested on a Mistake?" Wettstein has argued that the New
Theory of Reference (actually a family of theories based on the notion
of direct reference) cannot handle puzzles posed by Frege concerning
the cognitive significance of language. Since Wettstein finds the
arguments for the New Theory absolutely convincing, he is driven to
the conclusion that semantics has nothing to say about cognitive
significance. Perry argues that this is an overly pessimistic
assessment, and that Frege's puzzles can be solved by drawing a
distinction between the conditions under which an utterance expresses
a true proposition and the proposition expressed. Perry's principal
claim is that, while the New Theorists have mainly concerned
themselves with the latter, it is the former that should be identified
with cognitive significance. Thus arguments designed to show that the
proposition expressed by an utterance cannot be its cognitive
significance are irrelevant, and a broader theory of semantics can and
should account for both. In the discussion, I would like to raise the
issue of whether getting the semantics of propositional attitude
reports right forces a tighter connection between cognitive
significance of an utterance and the proposition expressed by an
utterance than either Wettstein or Perry is prepared to allow for.
--------------
NEXT WEEK'S SEMINAR
An Introduction to Situated Automata
Part II: Applications
Stan Rosenschein
November 5
This is the second of two lectures on the situated-automata approach
to the analysis and design of embedded systems. This approach seeks
to ground our understanding of embedded systems in a rigorous,
objective analysis of their informational properties, where
information is modeled mathematically in terms of correlations between
states of the system and conditions in the environment. In the first
talk we motivated the general framework, presented the central
mathematical ideas on how information is carried in the states of
automata, and related the mathematical properties of the model to key
theoretical issues in AI, including the nature of knowledge, its
representation in machines, the role of syntactic deduction,
"nonmonotonic" reasoning, and the relation of knowledge and action.
Some general technological implications of the approach, including
reduced reliance on conventional symbolic inference and increased
opportunities for parallelism were discussed.
In the second lecture, I will describe the application of the
situated-automata perspective to specific problems arising in the
design of integrated intelligent agents, including problems of
perception, planning and action selection, and linguistic
communication.
-------
∂28-Oct-87 1927 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU funds
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Oct 87 19:26:59 PST
Received: from Tenaya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 28 Oct 87 19:16:01-PST
Received: by Tenaya.Stanford.EDU (3.2/SMI-3.2)
id AA03183; Wed, 28 Oct 87 19:18:54 PST
Date: Wed, 28 Oct 87 19:18:54 PST
From: nilsson@Tenaya.Stanford.EDU (Nils Nilsson)
Message-Id: <8710290318.AA03183@Tenaya.Stanford.EDU>
To: ac@score
Subject: funds
I have some "not insubstantial" funds from an anonymous donor to
support research and education in "programming languages." Appropriate
uses of the funds would be to invite visiting faculty or researchers,
support PhD student work, seed projects that might lead to further
work that could get their own support, or travel. I'd be delighted
to hear proposals for the use of these funds. -Nils
∂29-Oct-87 1212 X3J13-mailer November X3J13 meeting
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Oct 87 12:12:47 PST
Received: from hplabs.HP.COM (hplabs.hpl.hp.com.#Internet) by SCORE.STANFORD.EDU with TCP; Thu 29 Oct 87 12:08:43-PST
Received: from hpfcla.HP.COM (hpfcla) by hplabs.HP.COM with SMTP ; Thu, 29 Oct 87 12:10:07 PST
Received: from hpfclp.HP.COM by hpfcla.HP.COM; Thu, 29 Oct 87 12:58:33 mst
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Thu, 29 Oct 87 12:57:42 mst
Received: from hpfcdcm by hpfcdcm.HP.COM; Thu, 29 Oct 87 12:57:30 mst
Return-Path: <dcm@hpfcdcm>
To: x3j13@sail.stanford.edu
Cc: mathis@ada20.isi.edu, dcm%hpfcdcm@hplabs.HP.COM
Subject: November X3J13 meeting
From: Dave_Matthews%hpfclp@hplabs.HP.COM
X-Mailer: mh6.5
Date: Thu, 29 Oct 87 12:57:27 MST
Message-Id: <5124.562535847@hpfcdcm>
Sender: dcm%hpfclp@hplabs.HP.COM
Last call for reservations and registrations. Please send me a
registration form in addition to making your reservations. I need to give
a tentative head count to the the hotel and the restaurant next Monday,
November 2, with final counts due the following Monday, November 9. So far
I've heard from the following people:
Kathy Chapman Digital Equipment Corporation
Walter van Roggen Digital Equipment Corporation
Dan Pierson Encore Computer Corporation
Sandra Loosemore Evans & Sutherland Computer Corp.
Steve Haflich Franz Inc.
Kevin Layer Franz Inc.
James Kempf Hewlett Packard Company
Dave Matthews Hewlett Packard Company
George Hadden Honeywell
Aaron Larson Honeywell
Thom Linden IBM
Mary Van Deusen IBM
Dick Gabriel Lucid, Inc.
JonL White Lucid, Inc.
Linda DeMichiel Lucid, Inc.
Christopher Dabrowski National Bureau of Standards
Chris Perdue Sun Microsystems
Sonya Keene Symbolics, Inc.
David Moon Symbolics, Inc.
David Bartley Texas Instruments
Patrick Dussud Texas Instruments
Daniel Bobrow Xerox Corporation
Pavel Curtis Xerox Corporation
Gregor Kiczales Xerox Corporation
Larry Masinter Xerox Corporation
The dinner selections thus far seem to favor duck, shrimp, chicken, and
lamb using a simple first choice heuristic.
First choice Second Choice
Shrimp XXXX XXXX
Lamb XXXX XXXXX
Sirloin XX XXXX
Duck XXXXX XX
Salmon XX XXXXX
Chicken XXX X
Veg. X
A few ski resorts have already opened, Jeff Rosenking is looking for other
skiers to join him on a trip the weekend before the meeting. Your ski
reservations, including lift tickets, can also be made through Lifeco
travel when you make your travel reservations.
There are some small board rooms available at the hotel if you would like
to use them Monday for committee meetings. Please let me know what times
you would like to reserve one so I can have one set aside for you.
By the way, I seem to have typoed my phone number in the last mailing. The
correct phone number is (303)229-2201.
Dave Matthews
--------------------------------------------------------------------------
X3J13 Meeting
11/16/87 - 11/18/87
Fort Collins, Colorado
The fifth meeting of X3J13 will be held Monday through Wednesday, November
16-18 at the University Park Holiday Inn in Fort Collins, Colorado. Monday
has been set aside for committee meetings, followed by the main meeting on
Tuesday and Wednesday. November is the perfect time to see fall (and
sometimes winter) in Colorado. Rocky Mountain National Park is
approximately one hour from Fort Collins.
Hewlett-Packard's travel affiliate, Lifeco Travel, has negotiated discount
airfares that you can obtain by calling:
800-521-8858 (in California)
800-722-8755 (elsewhere)
Ask to make a group reservation for X3J13. You may also make your room,
rental car, or airport limousine reservations through Lifeco at the same
time. Payment must be made by credit card. Tickets will be mailed via
registered mail. Late reservations can be express mailed at additional
cost.
A block of rooms is available at the University Park Holiday Inn at $46.50
plus tax per night. If you don't make reservations through Lifeco Travel,
please make your own reservations by calling (303)482-2626 and asking to
reserve a room in the "HP X3J13" block. Reservations will be held until 6
PM unless guaranteed by a major credit card. Non-smoking rooms are
available. Check-in and check-out times are 1 PM. The block of rooms will
be dropped on 11/2/87, but you should still be able to obtain the
discounted room rate on available rooms if you specify you are attending
the the "HP X3J13" conference.
Refreshments and lunch are being arranged for Tuesday and Wednesday. I
expect these arrangements will run $50 per person which I will collect at
the meeting. Please note any dietary restrictions so I can make the
necessary arrangements with the catering department.
If there is sufficient interest I would like to arrange a dinner Tuesday
evening at Cuisine, Cuisine. Cuisine, Cuisine is an intimate cafe offering
some the best and most unusual food in Northern Colorado. It is a very
small cafe which can only accommodate 60 total patrons, but they are
willing to put together a special banquet for us. To handle a group this
large in a short period of time they would like to limit the menu to 4
items. The list of possible entrees includes: Cajun roast duckling with
spice peach gravy, chicken boursin (double breast of chicken stuffed with
herbed cream cheese dressing and mushroom voloute' sauce), shrimp diane
(sauteed jumbo shrimp in a garlic cajun sauce), sirloin tips with mushrooms
and onions, poached salmon with a special sauce, or boned leg of lamb
stuffed with spinach and served with a dijon sauce. A vegetarian entree
will also be available. Entrees would be about 15 dollars, including soup
or salad. Appetizers, dessert, and beverage would be ala carte. Cuisine,
Cuisine accepts charge cards, but cash would also be welcome.
I would need to narrow this to the four items at least 2 weeks in advance
so they could make the necessary preparations. Note if you are interested
on the registration form and mark your first and second choice entrees.
Please note any dietary restrictions if this selection is not sufficient.
Fort Collins is approximately a one hour drive from Denver's Stapleton
International Airport. From the airport take I-270 or I-70 west to I-25
and go north on I-25 towards Cheyenne, Wyoming. Take the first Fort
Collins exit, #265, turn left and drive 5 miles to the College Avenue
intersection. Turn right and drive 3 miles to the Prospect Road
intersection. Turn left and the Holiday Inn is just across the railroad
tracks on the south side of the road. It shouldn't be hard to see since it
is 8 stories tall in an area with very few building over 2 stories.
Two limousine services provide shuttle service from Stapleton directly to
the Holiday Inn. Fort Collins Express (303-482-0505) leaves Stapleton on
the hour while the Front Range Airporter (303-221-5466) leaves Stapleton on
the half hour. Both are located in the baggage claim area. The charge is
$12 each way on the Express and $13 on the Airporter.
| Prospect Road ||
=========|====================== ||
HI | ||
M | ||
O | ||
U | ||
N | Drake Road North ||
T =========|====================== /\ ||
A | || ||
I |US 287/ College Avenue ||
N | ||I-25
S | ||
| Horsetooth Road ||
=========|====================== ||
| ||
| ||
| ||
| ||
| Harmony Road HP /||\
=========|=============================================||===========
| \||/ Exit 265
| ||
||
\/
Denver
Please return the following registration form by November 2 via electronic
mail to dcm%hpfclp@hplabs.hp.com or via US Mail to:
Dave Matthews
Hewlett-Packard Company
3404 E Harmony Road
Fort Collins, Colorado 80525
(303)229-2201
Feel free to contact me if you have any questions.
__________________________________________________________________________
X3J13 NOVEMBER MEETING REGISTRATION FORM
Name: __________________________________________________
Institution: __________________________________________________
Street Address: __________________________________________________
City, State, Zip: __________________________________________________
Phone: __________________________________________________
Network Address: __________________________________________________
Dinner 11/17 (y/n): __________________________________________________
First choice: __________________________________________________
Second choice: __________________________________________________
(Duck, chicken, shrimp, sirloin, salmon, lamb, vegetarian)
Dietary Restrictions: __________________________________________________
__________________________________________________
__________________________________________________
∂29-Oct-87 1413 @Score.Stanford.EDU:FACIL-mailer@SAIL.Stanford.EDU maybe we need a facilities meeting
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Oct 87 14:11:53 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 29 Oct 87 14:07:22-PST
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Oct 87 14:09:59 PST
Date: Thu 29 Oct 87 14:06:54-PST
From: Thomas Dienstbier <TOM@Score.Stanford.EDU>
Subject: maybe we need a facilities meeting
To: facil@Sail.Stanford.EDU
Message-ID: <12346437524.11.TOM@Score.Stanford.EDU>
I have thought of a few things that I think that the facilities committee
should decide on.
1. Charging on the new vax8700..Problem, the split between sponsored and
un-sponsored research. What do we do with Alumni accounts?
2. Sun maintenance for the suns in the building. Sun is offering a pretty
good deal. CSDCF is finding it harder to fine the parts we need for
repairs, which makes for long turn-around times.
3. File servers,, where do we put them. Does CSDCF have any say in this?
Can we say no,,we haven't any space?
4. Bell & Howell slide maker. What do we do with it? Should this be a part
of the cost center? Should we continue with the APS as part of the
cost center? We do not have the volume that was anticipated.
thanks
tom
-------
∂29-Oct-87 1451 @Score.Stanford.EDU:FACIL-mailer@SAIL.Stanford.EDU Re: maybe we need a facilities meeting
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Oct 87 14:51:11 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 29 Oct 87 14:45:22-PST
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Oct 87 14:48:00 PST
Received: by navajo.stanford.edu; Thu, 29 Oct 87 14:45:07 PST
Date: Thu, 29 Oct 87 14:45:07 PST
From: James E. Ball <ball@navajo.stanford.edu>
Subject: Re: maybe we need a facilities meeting
To: TOM@score.stanford.edu, facil@sail.stanford.edu
Tom,
Yes I think it would be a good idea to get the group together to discuss these
and perhaps some other issues relating to facilities usage and charges. I am
particularly interested in a rational approach to the Sun maintenance situation.
I am not yet sure that I completely understand the problem you mentioned on the
new VAX8700. Could you fill me in on the details?
Jim
∂29-Oct-87 1616 REGES@Score.Stanford.EDU summer instructors?
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Oct 87 16:16:39 PST
Date: Thu 29 Oct 87 16:11:08-PST
From: Stuart Reges <REGES@Score.Stanford.EDU>
Subject: summer instructors?
To: faculty@Score.Stanford.EDU
Office: CS-TAC 22, 723-9798
Message-ID: <12346460140.33.REGES@Score.Stanford.EDU>
In the past few summers we have started offering graduate level courses from
videotapes. While this is less than ideal, many of our grad students have
expressed sincere thanks for the opportunity to take advanced courses during
the summer. We are now in the process of choosing summer courses. I will
propose a number of taped courses, but it would be nice to get as many live
classes as possible. If you know of people who would like to visit this summer
who could teach courses (particularly mainstream courses like 143A, 240A, and
137), please let me know. The money for these appointments comes from a
separate source of University funding, so it won't eat into our unrestricted
money. Our normal formula is to pay a person $3250 for teaching a course, but
we could make other arrangements if someone's expertise warranted more.
-------
∂29-Oct-87 1725 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com Next Week's PLANLUNCH: David Poole
Received: from WARBUCKS.AI.SRI.COM by SAIL.STANFORD.EDU with TCP; 29 Oct 87 17:25:14 PST
Received: from venice by WARBUCKS.AI.SRI.COM via SMTP with TCP; Thu,
29 Oct 87 16:56:34-PST
Received: by venice (3.2/4.16) id AA18619 for
planlunch@warbucks.ai.sri.com; Thu, 29 Oct 87 16:55:04 PST
Date: Thu, 29 Oct 87 16:55:04 PST
From: Amy Lansky <lansky@venice.ai.sri.com>
Message-Id: <8710300055.AA18619@venice>
To: planlunch@warbucks.ai.sri.com
Subject: Next Week's PLANLUNCH: David Poole
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
DEFAULTS AND CONJECTURES:
HYPOTHETICAL REASONING FOR EXPLANATION AND PREDICTION
David Poole (dlpoole%watdragon.waterloo.edu@
relay.cs.net)
Logic Programming and Artificial Intelligence Group
University of Waterloo
11:00 AM, MONDAY, November 2
SRI International, Building E, Room EJ228
Classical logic has been criticised as a language for common sense
reasoning as it is monotonic. In this talk I wish to argue that the
problem is not with logic, but with how logic is used. An alternate
way to use logic is by using theory formation; logic tells us what a
theory implies, an inconsistency means that the theory cannot be true
of the world. I show how the simplest form of theory formation, namely
where the user supplies the possible hypotheses, can be used as a
basis for default reasoning and model-based diagnosis. This is the
basis of the "Theorist" system being built at the University of
Waterloo. I will discuss what we have learned from building and using
our system. I will also discuss distinctions which we have found to
be important in practice, such as between explaining observations and
making predictions; and between normality conditions (defaults) and
abnormality conditions (prototypes, conjectures, diseases). The
effects of these distinctions on recognition and prediction problems
will be presented along with algorithms, theorems and examples.
∂29-Oct-87 1733 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu reseach initiation grants
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Oct 87 17:33:27 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Thu 29 Oct 87 17:17:01-PST
Received: by lindy.stanford.edu; Thu, 29 Oct 87 17:18:41 PST
Received: by Forsythe.Stanford.EDU; Thu, 29 Oct 87 17:19:24 PST
Received: by NDSUVM1 (Mailer X1.24) id 4305; Thu, 29 Oct 87 18:56:42 CST
Date: 29 Oct 1987 19:51:05-EST (Thursday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Carl H. Smith" <CHSMITH@note.nsf.gov>
Subject: reseach initiation grants
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
The National Science Foundation program for Research Initiation
Awards has been expanded to the Directorate for Computer and
Information Science and Engineering. These awards are for
researchers in tenure track positions who have never received
research support from any agency of the Federal Government.
The competition for these awards is amongst persons applying for
research initiation grants only. The deadline for applications is
January 15, 1988. The differences between these awards and
regular grants are outlined below:
At most $60,000 for 24 months will be awarded, $70,000 if at
least $10,000 is for equipment. Overhead is limited to %10 of
the total award. Institutions are expected to to make a
substantial commitment to support the investigator's research.
The proposal must contain a signed statement by the Department
Head/Chair who specifies the institutional commitment.
For more information, call 202/357-7861 and ask for a copy of
form NSF 87-69, a brochure describing the research initiation
program in more detail. (TDD 202/357-7492)
∂29-Oct-87 2342 LOGMTC-request
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Oct 87 23:42:03 PST
Date: Thu 29 Oct 87 23:39:48-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
To: logmtc@Sail.Stanford.EDU
Message-ID: <12346541815.11.SF@CSLI.Stanford.EDU>
Seminar in Logic and Foundations
Ted Alper will begin speaking on the article "Logic tailored to
computational complexity" by Y. Gurevich, on Mon. Nov.2, 4:15,
Room 381-T, Stanford Math Corner.
S. Feferman
-------
∂30-Oct-87 0814 TAJNAI@Score.Stanford.EDU Computer Forum Meeting
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Oct 87 08:14:24 PST
Date: Fri 30 Oct 87 08:09:49-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Computer Forum Meeting
To: faculty@Score.Stanford.EDU
Message-ID: <12346634662.15.TAJNAI@Score.Stanford.EDU>
The Computer Forum meeting is scheduled for Friday, November 6
from 1:45 to 3:45 in Jacks 252. If you have agenda items, please
send me a message.
Carolyn
-------
∂30-Oct-87 0905 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu nsf grants
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Oct 87 09:04:54 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Fri 30 Oct 87 08:56:54-PST
Received: by lindy.stanford.edu; Fri, 30 Oct 87 08:58:52 PST
Received: by Forsythe.Stanford.EDU; Fri, 30 Oct 87 08:59:34 PST
Date: 30 Oct 1987 11:57:44-EST (Friday)
From: LBLUM%YKTVMZ.BITNET@forsythe.stanford.edu
To: DIANE@mills.berkeley.edu
Subject: nsf grants
Received: from FORSYTHE.STANFORD.EDU by IBM.COM on 10/29/87 at 17:59:07 PST
Received: from ernie.berkeley.edu by RELAY.CS.NET id aa02641;
29 Oct 87 20:42 EST
Received: from ucbvax.Berkeley.EDU by ernie.Berkeley.EDU (5.58/1.23)
id AA10268; Thu, 29 Oct 87 17:35:18 PST
Received: from Sushi.Stanford.EDU by ucbvax.Berkeley.EDU (5.58/1.27)
id AA12145; Thu, 29 Oct 87 17:34:33 PST
Message-Id: <8710300134.AA12145@ucbvax.Berkeley.EDU>
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Thu 29 Oct 87
Received: by lindy.stanford.edu; Thu, 29 Oct 87 17:18:41 PST
Received: by Forsythe.Stanford.EDU; Thu, 29 Oct 87 17:19:24 PST
Received: by NDSUVM1 (Mailer X1.24) id 4305; Thu, 29 Oct 87 18:56:42 CST
Date: 29 Oct 1987 19:51:05-EST (Thursday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Carl H. Smith" <CHSMITH@note.nsf.gov>
Subject: reseach initiation grants
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
The National Science Foundation program for Research Initiation
Awards has been expanded to the Directorate for Computer and
Information Science and Engineering. These awards are for
researchers in tenure track positions who have never received
research support from any agency of the Federal Government.
The competition for these awards is amongst persons applying for
research initiation grants only. The deadline for applications is
January 15, 1988. The differences between these awards and
regular grants are outlined below:
At most $60,000 for 24 months will be awarded, $70,000 if at
least $10,000 is for equipment. Overhead is limited to %10 of
the total award. Institutions are expected to to make a
substantial commitment to support the investigator's research.
The proposal must contain a signed statement by the Department
Head/Chair who specifies the institutional commitment.
For more information, call 202/357-7861 and ask for a copy of
form NSF 87-69, a brochure describing the research initiation
program in more detail. (TDD 202/357-7492)
∂30-Oct-87 1154 SLOAN@Score.Stanford.EDU Closing of Offices
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Oct 87 11:54:28 PST
Date: Fri 30 Oct 87 11:47:00-PST
From: Yvette Sloan <SLOAN@Score.Stanford.EDU>
Subject: Closing of Offices
To: CSD-List@Score.Stanford.EDU
Message-ID: <12346674198.20.SLOAN@Score.Stanford.EDU>
This is to inform you that the offices in Margaret Jacks Hall will close at
3:30 today so that we all can attend the CSL Halloween party.
-----Yvette
-------
∂30-Oct-87 1539 @Score.Stanford.EDU:FEIGENBAUM@SUMEX-AIM.STANFORD.EDU Duda
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Oct 87 15:39:52 PST
Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Fri 30 Oct 87 15:35:04-PST
Date: Fri, 30 Oct 87 15:29:58 PST
From: Edward Feigenbaum <FEIGENBAUM@SUMEX-AIM.STANFORD.EDU>
Subject: Duda
To: faculty@SCORE.STANFORD.EDU
Message-ID: <12346714790.43.FEIGENBAUM@SUMEX-AIM.STANFORD.EDU>
Re Nils' memo of 10/28/87 regarding Dick Duda as Lecturer, I just wanted
to say that I strongly support the idea. Dick is a superb teacher.
Ed
-------
∂30-Oct-87 1546 HEMENWAY@Score.Stanford.EDU Grey Tuesday Scheduled
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Oct 87 15:46:47 PST
Date: Fri 30 Oct 87 15:37:06-PST
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: Grey Tuesday Scheduled
To: faculty@Score.Stanford.EDU
Message-ID: <12346716086.14.HEMENWAY@Score.Stanford.EDU>
We have scheduled this year's Grey Tuesday evaluation meeting for
Tuesday, December 8 at 2:30 p.m. in Jacks 252. Please notify me of
any irreconcilable conflicts with this date before Wednesday, November
4, when I plan on announcing it to the students.
Sharon Hemenway & Mike Genesereth
-------
∂31-Oct-87 0914 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU annual report
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 31 Oct 87 09:14:35 PST
Received: from Tenaya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sat 31 Oct 87 09:10:55-PST
Received: by Tenaya.Stanford.EDU (3.2/SMI-3.2)
id AA05885; Sat, 31 Oct 87 08:46:33 PST
Date: Sat, 31 Oct 87 08:46:33 PST
From: nilsson@Tenaya.Stanford.EDU (Nils Nilsson)
Message-Id: <8710311646.AA05885@Tenaya.Stanford.EDU>
To: ac@score
Subject: annual report
The Dean's office attaches great importance to receiving annual
reports from the faculty. These reports play a big role as the School
negotiates its budget and billet requests for the coming year. Jim
Gibbons has been doing a fine job of conveying to the Provost the fact
that the faculty is under great stress and is extraordinarily
productive. He needs the data contained in the annual faculty reports
to back up these claims. Even though it adds to our stress to fill
these things out, the chore really does have a pay-off. Please do us
all a favor and get your report in to Anne Richardson
(richardson@score) in time for her to collect them and send them to
the Dean's office. An online version is attached to this message.
Anne also has hard copies of the form. Thanks, -Nils
----------
Stanford University
School of Engineering
Annual Faculty Report for Academic Year 1986-87
It is time again for a Faculty Report. This office finds it very useful to
have the information outlined below, and I appreciate you taking time to fill
out the form carefully. I realize that this represents only a summary
of your contributions to the School and misses completely your goodwill
and spirit which are equally important to our mission.
Please give this completed form to your departmental secretary by
December 1, 1985. Thanks for your help with this chore and
for your contributions to the School and the University.
Cordially,
Jim Gibbons,
Dean
(Please note: Information requested pertains to the period 9/1/86 to
8/31/87 only.)
NAME__________________________________________________________
Last, First, Middle
ACADEMIC RANK_________________________________________________
DEPARTMENT____________________________________________________
Teaching: (Please indicate by quarter, course title, number of units and
enrollment. Also include course or curriculum development, computer education
software tutorials, specially prepared television presentations or other
relevant work.)
Advising:
Number of freshman advisees -----
Number of other undergraduate advisees -----
Number of graduate advisees. Do not
include your PhD students. -----
Supervision of Ph.D. Candidates:
Number of students for which you
are principal dissertation advisor. -----
Number of students for which you
are on reading committee. -----
Publications: (Please indicate nature of work, such as books,
monographs, journals, technical reports, etc., giving title, date, pages and
publisher or issuing agency. Include only items actually published and for
archival journals, include papers accepted for publication. Do not include
papres submitted for publication.)
Books and contributions to books.
Archival Journal Articles.
Refereed Symposia Publications.
Technical Reports.
Presentations at Meetings and Symposia.
Research Projects:
Project title and Names of Principal Approx. annual dollar
Funding Source and co-Principal value of project for
Investigators, which you are
if any responsible.
University Service Other Than Teaching and Research: (Include
administrative duties and committee work.)
Professional Activities Outside the University: (Include offices in
professional organizations, services to government agencies or industry,
editorship of journals, and outside adminstrative or
public service.)
Honors and Awards:
Describe below any relevant activities or make any comments that do not fit
under previous categories.
∂31-Oct-87 1150 @Score.Stanford.EDU:golub@golubsun.cs.umd.edu Dean's report
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 31 Oct 87 11:49:45 PST
Received: from mimsy.umd.edu by SCORE.STANFORD.EDU with TCP; Sat 31 Oct 87 11:46:13-PST
Received: from golubsun.cs.umd.edu by mimsy.umd.edu (5.58/4.7)
id AA03708; Sat, 31 Oct 87 14:49:59 EST
Received: by golubsun.cs.umd.edu (5.54/3.14)
id AA29254; Sat, 31 Oct 87 14:47:35 EST
Date: Sat, 31 Oct 87 14:47:35 EST
From: golub@golubsun.cs.umd.edu (Gene Golub)
Return-Path: <golub@golubsun.cs.umd.edu>
Message-Id: <8710311947.AA29254@golubsun.cs.umd.edu>
To: ac@score.stanford.edu
Subject: Dean's report
From MAILER-DAEMON@mimsy.umd.edu Sat Oct 31 14:31:55 1987
Received: from by golubsun.cs.umd.edu (5.54/3.14)
id AA29219; Sat, 31 Oct 87 14:31:51 EST
Received: from golubsun.cs.umd.edu by mimsy.umd.edu (5.58/4.7)
id AA03569; Sat, 31 Oct 87 14:31:04 EST
Date: Sat, 31 Oct 87 14:31:04 EST
From: Mail Delivery Subsystem <MAILER-DAEMON@mimsy.umd.edu>
Subject: Returned mail: Host unknown
Message-Id: <8710311931.AA03569@mimsy.umd.edu>
To: <golub@golubsun.cs.umd.edu>
Status: R
----- Transcript of session follows -----
550 <ac@score>... Host unknown
----- Unsent message follows -----
Received: from golubsun.cs.umd.edu by mimsy.umd.edu (5.58/4.7)
id AA03555; Sat, 31 Oct 87 14:31:04 EST
Received: by golubsun.cs.umd.edu (5.54/3.14)
id AA29201; Sat, 31 Oct 87 14:28:40 EST
Date: Sat, 31 Oct 87 14:28:40 EST
From: golub@golubsun.cs.umd.edu (Gene Golub)
Return-Path: <golub@golubsun.cs.umd.edu>
Message-Id: <8710311928.AA29201@golubsun.cs.umd.edu>
To: ac@score, nilsson@tenaya.stanford.edu
Subject: Re: annual report
Nils,
I understand the Dean's need for much of this information but I don't think
it's really necessary every year. As our departmental representative to the
Dean's office, I think you ought to argue that a report of this nature every
two or three years would do. Perhaps on alternative years we could submit
our CV.
Also, I think much of the information requested could be obtained
from the administrative offices of the department without us being bothered
by seeing the request.
I hope you can present the case for us. Many Stanford faculty
members feel that the bureauocracy is rather heavy these days!
Regards,
Gene
∂01-Nov-87 1117 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU annual report
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Nov 87 11:17:27 PST
Received: from Tenaya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 1 Nov 87 11:12:48-PST
Received: by Tenaya.Stanford.EDU (3.2/SMI-3.2)
id AA06614; Sun, 1 Nov 87 10:25:13 PST
Date: Sun, 1 Nov 87 10:25:13 PST
From: nilsson@Tenaya.Stanford.EDU (Nils Nilsson)
Message-Id: <8711011825.AA06614@Tenaya.Stanford.EDU>
To: golub@golubsun.cs.umd.edu
Cc: ac@score
In-Reply-To: Gene Golub's message of Sat, 31 Oct 87 14:28:40 EST <8710311928.AA29201@golubsun.cs.umd.edu>
Subject: annual report
Gene, I think you are right. I'll bring up the matter at the
next SOE excom. -Nils
∂01-Nov-87 1727 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com PLANLUNCH REMINDER -- Monday -- David Poole
Received: from WARBUCKS.AI.SRI.COM by SAIL.STANFORD.EDU with TCP; 1 Nov 87 17:27:37 PST
Received: from venice by WARBUCKS.AI.SRI.COM via SMTP with TCP; Sun,
1 Nov 87 17:14:21-PST
Received: by venice (3.2/4.16) id AA21056 for
planlunch_reminder@WARBUCKS.ai.sri.com; Sun, 1 Nov 87 17:17:43 PST
Date: Sun 1 Nov 87 17:17:41-PST
From: Amy Lansky <LANSKY@venice.ai.sri.com>
Subject: PLANLUNCH REMINDER -- Monday -- David Poole
To: planlunch_reminder@WARBUCKS.ai.sri.com
Message-Id: <562814261.0.LANSKY@VENICE.ARPA>
Mail-System-Version: <SUN-MM(213)+TOPSLIB(128)@VENICE.ARPA>
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
DEFAULTS AND CONJECTURES:
HYPOTHETICAL REASONING FOR EXPLANATION AND PREDICTION
David Poole (dlpoole%watdragon.waterloo.edu@
relay.cs.net)
Logic Programming and Artificial Intelligence Group
University of Waterloo
11:00 AM, MONDAY, November 2
SRI International, Building E, Room EJ228
Classical logic has been criticised as a language for common sense
reasoning as it is monotonic. In this talk I wish to argue that the
problem is not with logic, but with how logic is used. An alternate
way to use logic is by using theory formation; logic tells us what a
theory implies, an inconsistency means that the theory cannot be true
of the world. I show how the simplest form of theory formation, namely
where the user supplies the possible hypotheses, can be used as a
basis for default reasoning and model-based diagnosis. This is the
basis of the "Theorist" system being built at the University of
Waterloo. I will discuss what we have learned from building and using
our system. I will also discuss distinctions which we have found to
be important in practice, such as between explaining observations and
making predictions; and between normality conditions (defaults) and
abnormality conditions (prototypes, conjectures, diseases). The
effects of these distinctions on recognition and prediction problems
will be presented along with algorithms, theorems and examples.
-------
∂01-Nov-87 1748 @Score.Stanford.EDU:FEIGENBAUM@SUMEX-AIM.STANFORD.EDU Annual Report
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Nov 87 17:42:30 PST
Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Sun 1 Nov 87 17:38:51-PST
Date: Sun, 1 Nov 87 16:33:55 PST
From: Edward Feigenbaum <FEIGENBAUM@SUMEX-AIM.STANFORD.EDU>
Subject: Annual Report
To: ac@SCORE.STANFORD.EDU
Message-ID: <12347250719.19.FEIGENBAUM@SUMEX-AIM.STANFORD.EDU>
Nils, as you know from my previous obstinacy concerning Annual Reports,
I wish to second Gene Golub's remarks and express my appreciation to him
for being vocal about this time-waster.
Ed
-------
∂02-Nov-87 0856 RICHARDSON@Score.Stanford.EDU CSD Faculty Lunch
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Nov 87 08:56:01 PST
Date: Mon 2 Nov 87 08:44:43-PST
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: CSD Faculty Lunch
To: faculty@Score.Stanford.EDU
Message-ID: <12347427448.19.RICHARDSON@Score.Stanford.EDU>
The CSD faculty lunch on Tuesday, November 3 will take place in MJH 146
at 12:15 -- with Ed Feigenbaum on the topic of the NRC Comp. Sci. & Tech.
Board.
-------
∂02-Nov-87 1040 HADDAD@Sushi.Stanford.EDU BATS: final call
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Nov 87 10:40:37 PST
Date: Mon 2 Nov 87 10:35:45-PST
From: Ramsey Haddad <HADDAD@Sushi.Stanford.EDU>
Subject: BATS: final call
To: aflb.su@Sushi.Stanford.EDU
Message-ID: <12347447660.12.HADDAD@Sushi.Stanford.EDU>
Any Stanford people who might be going to BATS should let me know by
this Wednesday so that I can give the Berkeley people an approximate
head count for lunch (which they provide).
I also need to know who will need parking permits and I will
coordinate car pooling. Hence, let me know if you:
(1) Are driving on your own and need a permit.
(2) Are driving and willing to take X passengers. (What is X?)
(3) Would like a ride from someone.
==========
BATS, the Bay Area Theory Seminar, will be held at UC Berkeley on
Thursday, November 12 in Sibley Auditorium in the Bechtel Engineering
Center.
The schedule is as follows:
10:10 Valerie King (Berkeley): An OMEGA(n↑(8/7)) Lower Bound on the
Randomized Complexity of Graph Properties
11:10 Cynthia Dwork (IBM): Interactive Proof Systems with a Weak Verifier.
12:10 Lunch
1:10 Michael Kearns (Harvard, Santa Cruz): Learning From Examples:
Lower Bounds and Malicious Errors
2:10 Anton T. Dahbura (AT&T Bell Laboratories): System-Level Diagnosis
for Multiprocessor Systems
-------
∂02-Nov-87 1409 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talks
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Nov 87 14:09:15 PST
Date: Mon 2 Nov 87 14:04:25-PST
From: Anil R. Gangolli <GANGOLLI@Sushi.Stanford.EDU>
Subject: Upcoming AFLB Talks
To: aflb.all@Sushi.Stanford.EDU
Office Phone: (415) 723-3605
Message-ID: <12347485647.8.GANGOLLI@Sushi.Stanford.EDU>
PLEASE NOTE THE FOLLOWING:
* Next week, BATS takes place Thursday at Berkeley, so the AFLB talk
will take place on Friday, Nov. 13, at 10:30am.
* The talk by A. Subramanian on Friday, Nov. 6, takes place at 1:00pm,
NOT 1:15pm as indicated in an earlier message.
THIS WEEK'S TALK:
5-November-87: Tomas Feder (Stanford)
Optimal Algorithms
for Approximate Clustering
The clustering problem is that of partitioning a given set of n points
into k groups, called clusters, so that points within each cluster are
near each other. Two objective functions frequently used to measure
the performance of a clustering algorithm are (a) the maximum distance
between pairs of points in the same cluster, and (b) the maximum
distance between the points and "cluster centers"; we refer to the
chosen measure as the "cluster size".
We show that, while there is a polynomial time approximation scheme to
estimate the number of clusters that are needed for a fixed cluster
size, one cannot approximate the optimal cluster size for a fixed
number of clusters within a factor close to 2 in polynomial time,
unless P=NP. We present an algorithm which achieves this factor of 2
in time O(n log k), and show that this running time is optimal in the
algebraic decision tree model. Our approach can be extended to provide
optimal O(n log k) approximation algorithms for the related k-centers,
k-suppliers, and weighted k-suppliers problems.
This talk represents joint work with Daniel Greene at Xerox PARC.
***** Time and place: Thurs, November 5, 12:30pm in MJH 352 (Bldg. 460) *****
NEXT WEEK'S TALK:
13-November-87: Anton Dahbura (AT&T Bell Labs, Murray Hill)
Optimization Techniques for Testing Finite-State Automata
In this talk, methods are discussed for checking that a
black-box implementation of a finite-state automaton is
functionally equivalent to its specification. This problem,
known as design checking, or testing, is a special case of
the well-known machine distinguishability problem studied
for over thirty years. The design checking problem has
become increasingly important in communications network
design for testing the conformance of a network layer proto-
col to its specification. It has been shown recently by the
author that under certain conditions, optimization tech-
niques can be used to design highly effective test sequences
for testing a protocol which is modeled as an FSA. Tech-
niques for extending these techniques under less ideal con-
ditions are considered and some open problems are presented.
***** Time and place: Fri, November 13, 10:30pm in MJH 352 (Bldg. 460)
********* NOTE UNUSUAL DAY AND TIME **********
ANOTHER TALK OF AFLB INTEREST:
6-November-1987: Ashok Subramanian (Stanford)
Scatter-free Network Stability Problems
We introduce the notion of Network Stability Problems. A network is a
directed graph with a gate at each internal vertex, and with boolean inputs
and outputs. (A gate assigns to each output edge a boolean function of the
values on its input edges.) A network can have cycles. A stable
configuration of a network is an assignment of values to the edges of the
network in a manner consistent with the inputs and with the gate equations.
Network stability problems are questions about the stable configurations of
a network, e.g., are there any?, how do we find one fast?, how many are
there?, and so on.
We study network stability problems as a function of the set of gates
allowed. It is easy to show that the problem `Is there a stable
configuration?' is complete for NP if no restriction is placed on the set
of gates.
We introduce the notion of `scatter'. A restriction of a gate is a gate
obtained by assigning specific values to some (perhaps none) of the inputs,
and then discarding irrelevant inputs and outputs, i.e., inputs that
influence no outputs, and outputs that are fixed. A gate has scatter if it
has a restriction with more outputs than inputs. There is a simple
linear-time algorithm for finding a stable configuration of a network if
every gate lacks scatter.
Finally, we show how these ideas lead to a simple linear-time algorithm for
the stable roommates problem. The stable roommates problem is this: there
are $2n$ persons in a world with $n$ two-bedroom apartments; the task is to
decide who rooms with whom. Each person ranks all the other persons in
order of preference. An assignment is unstable if there are two people who
prefer each other to their current roommates. [This problem already has a
linear-time solution; we think ours is simpler.]
***** Time and place: Fri, November 6, 1:00pm in MJH 352 (Bldg. 460) *****
-------
∂03-Nov-87 1037 TAJNAI@Score.Stanford.EDU AT&T Bell call for Fellowship Nominees
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Nov 87 10:37:24 PST
Date: Tue 3 Nov 87 10:30:52-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: AT&T Bell call for Fellowship Nominees
To: FACULTY@Score.Stanford.EDU
cc: HAYES-ROTH@SUMEX-AIM.Stanford.EDU
Message-ID: <12347708916.13.TAJNAI@Score.Stanford.EDU>
We received a letter from Dr. Patel of AT&T requesting 3 nominations
for the Bell Fellowship. The fellowship is for 4 years
(current holders: John Lamping, Andrew Golding, Jonathan Traugott and
Tomas Feder) and we should nominate either first or second year
students.
NOMINATIONS SHOULD BE RECEIVED BY FRIDAY, NOVEMBER 20.
To make it easier for you to nominate, I'm listing the eligible
students, e.g., US citizens who do not have fellowships and who
are first/second year.
First year: Donald Geddis
Sheralyn Listgarten
Second year: Craig Chambers
Timothy Fernando
Barry Hayes
David Mellinger
Steven Nowick
Martin Rinard
David Salesin
Alexander Wang
Michael Wolverton
Carolyn
-------
∂03-Nov-87 1136 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU AT&T Bell call for Fellowship Nominees
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Nov 87 11:36:29 PST
Received: from Tenaya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 3 Nov 87 11:30:01-PST
Received: by Tenaya.Stanford.EDU (3.2/SMI-3.2)
id AA08576; Tue, 3 Nov 87 11:33:18 PST
Date: Tue, 3 Nov 87 11:33:18 PST
From: nilsson@Tenaya.Stanford.EDU (Nils Nilsson)
Message-Id: <8711031933.AA08576@Tenaya.Stanford.EDU>
To: TAJNAI@Score.Stanford.EDU
Cc: FACULTY@Score.Stanford.EDU, HAYES-ROTH@SUMEX-AIM.Stanford.EDU
In-Reply-To: Carolyn Tajnai's message of Tue 3 Nov 87 10:30:52-PST <12347708916.13.TAJNAI@Score.Stanford.EDU>
Subject: AT&T Bell call for Fellowship Nominees
I'd be happy with any of the candidates you mention. -Nils
∂03-Nov-87 1546 TOM@Score.Stanford.EDU Campus-wide power shut-down
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Nov 87 15:46:32 PST
Date: Tue 3 Nov 87 15:35:52-PST
From: Thomas Dienstbier <TOM@Score.Stanford.EDU>
Subject: Campus-wide power shut-down
To: staff@Score.Stanford.EDU, csd@Score.Stanford.EDU,
faculty@Score.Stanford.EDU
Message-ID: <12347764438.38.TOM@Score.Stanford.EDU>
We have been notified by the people at Operations and Maintenance
that on December 20, the electrical power on campus including Margaret
Jacks Hall will be turned off from 0700 thru 1600 hours. Computer systems
in Jacks will be brought down prior to this, somewhere around 0630
and hope to have things running again soon after 1600 hours.
Experience from our last power outages were less than what were expected,
resulting in much longer downtimes do to damaged disk drives.
The reason for the shut-down is the continued work in conjunction
with the University COGEN plant.
tom
-------
∂03-Nov-87 1835 TAJNAI@Score.Stanford.EDU Bell message correction
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Nov 87 18:34:56 PST
Date: Tue 3 Nov 87 18:29:53-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Bell message correction
To: faculty@Score.Stanford.EDU
Message-ID: <12347796118.30.TAJNAI@Score.Stanford.EDU>
Timothy Fernando should not have been on the list -- he is not
a US citizen.
Carolyn
-------
∂04-Nov-87 0641 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu French-Israeli Conference on Combinatorics and Algorithms
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Nov 87 06:41:00 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Wed 4 Nov 87 06:34:18-PST
Received: by lindy.stanford.edu; Wed, 4 Nov 87 06:36:39 PST
Received: by Forsythe.Stanford.EDU; Wed, 4 Nov 87 06:37:34 PST
Received: by NDSUVM1 (Mailer X1.24) id 2231; Wed, 04 Nov 87 08:17:56 CST
Date: 4 Nov 1987 09:11:58-EST (Wednesday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Aviezri Fraenkel <FRAENKEL%WISDOM.BITNET@forsythe.stanford.edu>
Subject: French-Israeli Conference on Combinatorics and Algorithms
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
Appended below is a first announcement about a French-Israeli Conference
on Combinatorics and Algorithms, to take place in November, 1988, in
Israel. Participants from other countries are also invited to apply.
Please post the announcement.
With many thanks, Aviezri S. Fraenkel.
>>>>>>>>><<<<<<<>>>><<<<<<<>>><<<<<<<>><<<<<<<<>>><<<<<<<>>><<<<<<<<>><
Please Post
FRENCH-ISRAELI CONFERENCE ON COMBINATORICS AND ALGORITHMS
First Announcement
Date: Week of Nov 13-17, 1988 Place: Israel
Sponsors: CNRS, France NCRD, Israel
Information: C. Weintraub, Appl Math & Comp Sc, Weizmann Inst Science,
Rehovot 76100, Israel; maweintr@weizmann.bitnet
J. Bond, LRI, Universite de Paris Sud, bat 490,
91405 Orsay, Cedex, France; bond@lri.uucp
Abstracts of up to 200 words due by July 1, 1988, should be sent to
A.S. Fraenkel, Appl Math & Comp Sc, Weizmann Inst of Science, Rehovot
76100, Israel; fraenkel@wisdom.bitnet
Proceedings of refereed full-length papers are planned.
Participants from other countries are also invited to apply.
Organizing Committee
ISRAEL FRANCE
N. Alon, Math, Tel Aviv Univ J.-C. Bermond, CNRS, U. Paris-Sud
G. Ariely, NCRD, Jerusalem J. Bond, LRI, U. Paris-Sud
A.S. Fraenkel, Weizmann Inst M.M. Deza, CNRS, U. Paris 6
M. Golumbic, IBM Israel Sc Ctr P. Frankl, CNRS, U. Paris 6
E. Shamir, Math, Hebrew Univ
---------Detach and Air-Mail or Email to Mrs. Carol Weintraub---------
P L E A S E P R I N T
I'd like to receive further information []
I'd like to give a lecture Yes [] No []
Tentative title: __________________________________________________
Name: _____________________________________________________________
Address: __________________________________________________________
__________________________________________________________
Remarks: __________________________________________________________
__________________________________________________________
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
∂04-Nov-87 1526 @Score.Stanford.EDU:ullman@navajo.stanford.edu Visit of Maria Klawe
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Nov 87 15:26:17 PST
Received: from navajo.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 4 Nov 87 15:14:55-PST
Received: by navajo.stanford.edu; Wed, 4 Nov 87 15:15:39 PST
Date: Wed, 4 Nov 87 15:15:39 PST
From: Jeff Ullman <ullman@navajo.stanford.edu>
Subject: Visit of Maria Klawe
To: faculty@score.stanford.edu
Maria Klawe would like to speak with interested
faculty regarding the integration of IBM PC/RT's into
our environment---what experiences have we had, what are the
problems, what would it take to get us more interested?
(Maria now works for IBM's ACIS; she was formerly a manager
in the theory group.)
I would appreciate those with interest in the matter agreeing to a
time slice to speak with her on Dec. 1 (Tuesday).
Right now, I have <= 11AM and >= 2PM open.
---jeff
∂04-Nov-87 2031 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com Special last minute seminar -- thursday -- Jean-Louis Lassez
Received: from WARBUCKS.AI.SRI.COM by SAIL.STANFORD.EDU with TCP; 4 Nov 87 20:31:37 PST
Received: from venice by WARBUCKS.AI.SRI.COM via SMTP with TCP; Wed,
4 Nov 87 16:54:14-PST
Received: by venice (3.2/4.16) id AA23372 for
planlunch@warbucks.ai.sri.com; Wed, 4 Nov 87 16:50:48 PST
Date: Wed, 4 Nov 87 16:50:48 PST
From: Amy Lansky <lansky@venice.ai.sri.com>
Message-Id: <8711050050.AA23372@venice>
To: planlunch@warbucks.ai.sri.com
Subject: Special last minute seminar -- thursday -- Jean-Louis Lassez
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
CONSTRAINT LOGIC PROGRAMMING
Jean-Louis Lassez
11:00 AM, THURSDAY, November 5
SRI International, Building E, Room EJ228
∂04-Nov-87 2047 @CSLI.Stanford.EDU:emma@russell.stanford.edu CSLI Calendar, November 5, 3:6
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Nov 87 20:47:22 PST
Received: from russell.stanford.edu by CSLI.Stanford.EDU with TCP; Wed 4 Nov 87 17:10:30-PST
Received: from csli by russell.stanford.edu (3.2/4.7); Wed, 4 Nov 87 17:08:35 PST
Date: Wed, 04 Nov 87 17:08:28 PST
From: emma@russell.stanford.edu
Subject: CSLI Calendar, November 5, 3:6
------- Blind-Carbon-Copy
To: friends@csli.stanford.edu
Subject: CSLI Calendar, November 5, 3:6
Date: Wed, 04 Nov 87 17:08:28 PST
From: emma
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
5 November 1987 Stanford Vol. 3, No. 6
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 5 November 1987
12 noon TINLunch
Ventura Hall Reading: "The Logicist Conception of Knowledge
Conference Room is too Narrow---But so is McDermott's"
by Stanley J. Rosenschein
Discussion led by the author
(Stan@warbucks.ai.sri.com)
No abstract
2:15 p.m. CSLI Seminar
Room G-19 An Introduction to Situated Automata
Redwood Hall Part II: Applications
Stanley J. Rosenschein (Stan@warbucks.ai.sri.com)
Abstract in last week's calendar
3:30 p.m. Tea
Ventura Hall
--------------
NEW PUBLICATIONS
The following reports have recently been published. They may be
obtained by writing to Trudy Vizmanos, CSLI, Ventura Hall, Stanford,
CA 94305-4115 or publications@csli.stanford.edu.
97. Constituent Coordination in HPSG
Derek Proudian and David Goddeau
98. A Language/Action Perspective on the Design of Cooperative Work
Terry Winograd
99. Implicature and Definite Reference
Jerry R. Hobbs
100. Thinking Machines: Can There be? Are we?
Terry Winograd
101. Situation Semantics and Semantic Interpretation in
Constraint-based Grammars
Per-Kristian Halvorsen
102. Category Structures
Gerald Gazdar, Geoffrey K. Pullum, Robert Carpenter, Ewan Klein,
Thomas E. Hukari, Robert D. Levine
103. Cognitive Theories of Emotion
Ronald Alan Nash
104. Toward an Architecture for Resource-bounded Agents
Martha E. Pollack, David J. Israel, and Michael E. Bratman
105. On the Relation Between Default and Autoepistemic Logic
Kurt Konolige
106. Three Responses to Situation Theory
Terry Winograd
--------------
CURRENT VISITORS
SYLVAIN BROMBERGER
Professor of Philosophy
Department of Linguistics and Philosophy
Massachusetts Institute of Technology
Dates of visit: September 1987--July 1988
Bromberger is currently interested in the philosophy of linguistics
and in rational acquisition of knowledge. In the philosophy of
linguistics he is working on conceptual issues arising in
phonology/phonetics. Under rational acquisition of knowledge he is
interested in the limits that constrain search for knowledge guided by
questions and in the semantics of interrogatives. He is a regular
participant of the RATAG project.
KEITH DEVLIN
Reader in Mathematics
Department of Mathematics
University of Lancaster
Dates of visit: September 1987--August 1988
Devlin is a mathematical logician. About three years ago, his
interest in set theory gave way (via a brief passage through computer
science) to a desire to work out a genuine, mathematical theory of
information. He thought that the approach to this problem adopted by
Barwise and his colleagues at CSLI was the best way to proceed, and
has subsequently thrown his lot in with this gang. He is presently
writing a book on situation theory.
CARL GINET
Chair, Sage School of Philosophy
Cornell University
Dates of visit: June--December 1987
Ginet is a philosopher on sabbatic leave from Cornell. During his
stay at CSLI, he will be finishing a book on action, catching up on
the literature in epistemology, and refining software he has written
that guides students in constructing derivations in formal logic.
KIYONG LEE
Department of English
Korea University
Dates of visit: December 1986--December 1987
Lee is visiting CSLI on a senior research grant from the
Korean-American Educational Commission and the Council for
International Exchange of Scholars. He hopes to acquaint himself with
new developments in situation theory and semantics, and to write an
introductory book for Korean readers. While working on some
foundational aspects of situation theory, he is very much interested
in testing its adequacy in treating some concrete problems, especially
those related to negation, quantification, and tense/aspect in Korean.
He is participating in the STASS project while he is here and also
continues developing a computationally tractable, functor-driven,
phrase structure grammar of natural language by amalgamating a
categorial grammar with HPSG.
SALLY MCCONNELL-Ginet
Professor
Department of Modern Languages and Linguistics
Cornell University
Dates of visit: June--December 1987
During her time at CSLI (the first half of a year's sabbatic leave
from Cornell), McConnell-Ginet will be working on a book about formal
approaches to the analysis of vagueness. She will also be working on
a semantics text for linguistics that she and Gennaro Chierchia are
coauthoring.
HIDEYUKI NAKASHIMA
Senior Researcher
Man-Machine Systems Section
Electrotechnical Laboratory
Dates of visit: September 1987--August 1988
Nakashima is interested in knowledge representation, reasoning, and
learning. He is also interested in a model of language acquisition.
He has his own knowledge-representation system based on logic
programming, called Uranus. He is planning to create a programming
language based on situation theory.
RONALD NASH
Dates of visit: January 1987--July 1988
Nash is at CSLI on a postdoctoral fellowship from the Social Sciences
and Humanities Research Council of Canada. He is interested in the
philosophy of mind and normative psychology, and is particularly
interested in the work of CSLI's RATAG and DIA projects with respect
to the cognitive theory of emotion on which he has recently worked.
He hopes to construct a more formal model while he is here, and will
be looking at the various formal models being considered at CSLI.
KASPER OSTERBYE
Institute of Electronical Systems, Aalborg
University of Aarhus
Dates of visit: September 1986--September 1987
Osterbye's recent work has been on programming languages, especially
dealing with interactive higher-level debugging. At CSLI, he is
participating in the SDL project.
GORDON PLOTKIN
Professor
Department of Computer Science
University of Edinburgh
Dates of visit: September 1987--October 1988
Plotkin is interested generally in issues of language and logic and
particularly in the modeling and formalization of situation theory and
in learning situation semantics. He is also interested in a variety
of issues in the denotational semantics of programming languages, such
as concurrency and probabilistic computation, and also in a usefully
implementable general proof theory. He is an active participant in
the STASS project.
BILL ROUNDS
Associate Professor
Department of Computer Science
University of Michigan
Dates of visit: September 1987--June 1988
Rounds is a computer scientist interested in mathematical and
computational linguistics. He is developing logics for expressing
grammars and for understanding grammatical properties, with special
emphasis on unification-based grammatical systems. These logics can
also be used directly in implementations of such systems. He is
participating in the MOST project at CSLI.
HIROYUKI SUZUKI
Researcher
Systems Tokyo Research Department
Corporate Engineering Division
Matsushita Electric Industrial Co.,Ltd.
Dates of visit: September 1986--March 1988
Suzuki's main interest lies in building Japanese dialog systems. He
is currently interested in designing a representation language for a
computer as a participant of conversations, and clarifying strategies
for generating sentences that are employed by human beings to keep
conversations coherent.
SYUN TUTIYA
Associate Professor
Department of Philosophy
Faculty of Letters
Chiba University
Dates of visit: November 1986--September 1988
Tutiya is interested in the development of speech acts theory within
the framework of situation theory and situation semantics. He is also
interested in quantification in Japanese, in Frege and the history of
logic after him, and has been translating `Situations and Attitudes'
into Japanese. He is an active participant in the STASS project.
SUSON YOO
Doctoral Candidate and Instructor
Department of Linguistics
Korea University
Dates of visit: March 1987--February 1988
Yoo is continuing her work with Kiyong Lee, currently at CSLI, and is
especially interested in learning more about situation theory and
unification grammar and investigating their universal ramifications by
testing their linguistic significance and computational applicability
to the analysis of Korean.
LOTFI ZADEH
Professor
Department of Computer Science
University of California, Berkeley
Dates of visit: Fall Quarter 1987
Zadeh developed "fuzzy" logic and set theory---the central idea being
that truth or membership in a set isn't simply binary, but permits a
continuum of values. He has attended many CSLI functions over the
past four years, especially on Thursdays, and we are pleased that he
has arranged to be here several days a week during fall quarter.
------- End of Blind-Carbon-Copy
∂04-Nov-87 2153 LOGMTC-request Drusinsky talk next Friday
Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 4 Nov 87 21:53:51 PST
Received: from sun.Sun.COM by Sun.COM (4.0/SMI-3.2)
id AA17730; Wed, 4 Nov 87 21:49:17 PST
Received: from coraki.UUCP by sun.Sun.COM (4.0/SMI-4.0)
id AA04957; Wed, 4 Nov 87 21:55:45 PST
Received: by coraki.uucp (3.2/SMI-1.2)
id AA03834; Wed, 4 Nov 87 21:50:32 PST
Date: Wed, 4 Nov 87 21:50:32 PST
From: coraki!pratt@Sun.COM (Vaughan Pratt)
Message-Id: <8711050550.AA03834@coraki.uucp>
To: conmod@navajo.stanford.edu
Subject: Drusinsky talk next Friday
Cc: logmtc@sail.stanford.edu
Date: 11/13/1987 Event : Seminar
Day : Friday Person: Doron Drusinsky
Time: 2:15 pm From : Dept App Math and CS, Weizmann
Room: Bldg 460 Rm 301 Title : On Synchronized Statecharts
Abstract
Finite State Machines (FSM's) have been one of the main formalisms
underlying the prevailing approaches to the description and synthesis
of communication protocols, text editors, distributed systems, digital
components, and many other complex systems. Two of the major drawbacks
of FSM's, however, are their sequentiality and flatness. Without
catering naturally for concurrency and multi-level descriptions a
state-based approach is bound to be unsuitable for describing the
behavior of large and complex systems.
Recently, an attempt at overcoming these limitations has been made with
the advent of statecharts (of David Harel) which extend the familiar
FSM's in several fundamental ways, while retaining both their formality
and their visual appeal. Statecharts enable modular, hierarchical
descriptions of system behavior, catering for concurrency,
state-history, and multi-level descriptions.
The talk will include results of an assessment of the feasibility of
using statecharts in the realm of reactive system programming and
communication protocols, with the support of some automata-theoretic
results for finite and infinite inputs. This work was carried out
under the supervision of Prof. David Harel.
∂05-Nov-87 0757 RICHARDSON@Score.Stanford.EDU NSF
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 5 Nov 87 07:56:58 PST
Date: Thu 5 Nov 87 07:52:01-PST
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: NSF
To: faculty@Score.Stanford.EDU
Message-ID: <12348204286.15.RICHARDSON@Score.Stanford.EDU>
I have a program announcement from NSF on the following:
Undergraduate Science, Engineering and Mathematics Education -- INSTRUMENTATION
AND LABORATORY IMPROVEMENT
If you would like a copy, please let me know.
-Anne
-------
∂05-Nov-87 0942 @WARBUCKS.AI.SRI.COM,@malibu:olender@malibu.ai.sri.com SPECIAL LAST MINUTE SEMINAR / TODAY / JEAN-LOUIS LASSEZ.
Received: from WARBUCKS.AI.SRI.COM by SAIL.STANFORD.EDU with TCP; 5 Nov 87 09:42:52 PST
Received: from malibu by WARBUCKS.AI.SRI.COM via SMTP with TCP; Thu,
5 Nov 87 08:54:18-PST
Received: by malibu (3.2/4.16) id AA06736 for
planlunch@warbucks.ai.sri.com; Thu, 5 Nov 87 08:47:28 PST
Date: Thu, 5 Nov 87 08:47:28 PST
From: Margaret Olender <olender@malibu.ai.sri.com>
Message-Id: <8711051647.AA06736@malibu>
To: planlunch@warbucks.ai.sri.com
Subject: SPECIAL LAST MINUTE SEMINAR / TODAY / JEAN-LOUIS LASSEZ.
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
CONSTRAINT LOGIC PROGRAMMING
Jean-Louis Lassez
11:00 AM, THURSDAY, November 5
SRI International, Building E, Room EJ228
ABSTRACT
Dr. Jean-Louis Lassez
IBM Thomas J. Watson Research Center
Yorktown Height, New York
We present the Constraint Logic Programming (CLP) scheme, which
provides a framework for the formal foundations of a class of
programming languages. These languages share the same essential
declarative and operational semantics inherited from the logic
paradigm. Their expressive power is enhanced because using
constraints allows us to state properties directly in the domain of
application as opposed to the fixed domain imposed by logic
programming. Furthermore, objects can be represented implicitly as
opposed to having bindings to variables. We also describe CLP(R), an
example of the scheme, which is a language in the domain of real
arithemetic. At the core of the CLP(R) interpreter is a variant of
the simplex algorithm. The integration of such a powerful solver
within a programming language raises a number of interesting questions
such as incrementality, canonical representation of the constraints
and parallelism. We conclude with a discussion of these problems.
∂05-Nov-87 1000 HEMENWAY@Score.Stanford.EDU [Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>: Grey Tuesday Scheduled]
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 5 Nov 87 10:00:00 PST
Date: Thu 5 Nov 87 08:56:22-PST
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: [Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>: Grey Tuesday Scheduled]
To: faculty@Score.Stanford.EDU
Message-ID: <12348216000.21.HEMENWAY@Score.Stanford.EDU>
I intended to cc the faculty on this message just sent out to the Ph.D.
students but neglected to so I am now forwarding a copy.
Sharon
---------------
Mail-From: HEMENWAY created at 5-Nov-87 08:50:19
Date: Thu 5 Nov 87 08:50:17-PST
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: Grey Tuesday Scheduled
To: phd@Score.Stanford.EDU
Message-ID: <12348214893.21.HEMENWAY@Score.Stanford.EDU>
Grey Tuesday, the first evaluation meeting of the 1987-88 year, has
been scheduled for Tuesday, December 8. Within the next couple of
weeks, I will be sending out to each of you a copy of your current
record for review. In the meanwhile, I request that those of you who
were asked to complete requirements before the Grey Tuesday meeting
send me an update on their status. I worry that there may have been
some things that did not get properly recorded in the past few
unsettled months so please don't hesitate to repeat messages that you
may have sent earlier.
Sharon
-------
-------
∂05-Nov-87 1455 TAJNAI@Score.Stanford.EDU SUNRISE CLUB MEETS MONDAY, NOV. 16
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 5 Nov 87 14:55:32 PST
Date: Thu 5 Nov 87 14:41:00-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: SUNRISE CLUB MEETS MONDAY, NOV. 16
To: faculty@Score.Stanford.EDU
Message-ID: <12348278740.42.TAJNAI@Score.Stanford.EDU>
TO COMPUTER SCIENCE FACULTY MEMBERS:
A reminder that the Sunrise Club will meet Monday, November 16 at
7:30 a.m. We meet at Tresidder Union, Oak Lounge West. Professor
Joe Goodman will speak on "Optics as an Interconnect Technology."
Jim Gibbons will be out of town on that day, but Professor John
Linvill has kindly agreed to host the meeting.
Please ask your graduate students to attend. Grad students are
always most welcome and the Sunrise members are encouraged to
mingle with them!
Please let Carolyn Tajnai know if you can attend by sending a
message to her at TAJNAI@SCORE. Please ask CS grad students to
also reply via electronic mail to Carolyn.
As always, breakfast will be served.
Hope to see you there. Thanks.
Joanne Chequer
Sunrise Club coordinator
-------
∂05-Nov-87 1551 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com Next MONDAY's Planlunch Seminar -- Anand Rao
Received: from WARBUCKS.AI.SRI.COM by SAIL.STANFORD.EDU with TCP; 5 Nov 87 15:50:57 PST
Received: from venice by WARBUCKS.AI.SRI.COM via SMTP with TCP; Thu,
5 Nov 87 14:37:29-PST
Received: by venice (3.2/4.16) id AA24068 for
planlunch@warbucks.ai.sri.com; Thu, 5 Nov 87 14:25:04 PST
Date: Thu, 5 Nov 87 14:25:04 PST
From: Amy Lansky <lansky@venice.ai.sri.com>
Message-Id: <8711052225.AA24068@venice>
To: planlunch@warbucks.ai.sri.com
Subject: Next MONDAY's Planlunch Seminar -- Anand Rao
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
EVOLVING KNOWLEDGE AND TMS
Anand S. Rao (ANAND@IBM.COM)
IBM T.J. Watson Research Center and Sydney University
(joint work with
Normal Y. Foo
IBM Systems Research Education Center and Sydney University)
11:00 AM, MONDAY, November 9
SRI International, Building E, Room EJ228
The traditional view of knowledge in the AI literature has been that
'Knowledge' is 'true belief'. The semantic account of this notion
suffers from a major problem called Logical Omniscience, where the
agent knows all valid formulas and his knowledge is closed under
implication. In this talk we propose an alternative viewpoint where
knowledge or EVOLVING KNOWLEDGE (as we call it) is treated as
'indefeasibly justified true belief'. This notion of knowledge solves
the problem of logical omniscience and also captures the
resource-bounded reasoning of agents in a natural way. We give the
semantics and axiomatization of this logic of evolving knowledge and
discuss its properties.
The logic of evolving knowledge also serves as the logical foundation
for the Truth Maintenance System (TMS). We provide a transformation to
and from TMS nodes to formulas in this logic. We show that a set of
nodes has a 'well founded labelling' iff their corresponding IN nodes
are 'satisfiable' in this logic and their corresponding OUT nodes are
'not satisfiable' in this logic. We conclude the talk by comparing our
logic with Autoepistemic Logic, Deduction model of Belief and the
Awareness model of belief.
∂05-Nov-87 1703 TOM@Score.Stanford.EDU MJH Ethernet down-time schedule
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 5 Nov 87 17:03:06 PST
Date: Thu 5 Nov 87 16:57:24-PST
From: Thomas Dienstbier <TOM@Score.Stanford.EDU>
Subject: MJH Ethernet down-time schedule
To: csd@Score.Stanford.EDU, staff@Score.Stanford.EDU,
faculty@Score.Stanford.EDU
Message-ID: <12348303570.22.TOM@Score.Stanford.EDU>
We plan to upgrade the ethernet in Margaret Jacks Hall on Monday, November
9, from 0900 to 1300 hours. The ramification of this is that all network
connected systems/machines will cease to communicate with other hosts within
MJH and outside of MJH until the upgrade is complete. This includes Tips,
workstations, mainframes and printers. With the addition of more workstations
and equipment in general, it has become mandatory that this upgrade be done.
tom
-------
∂05-Nov-87 1714 TOM@Score.Stanford.EDU SUSHI MOVE
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 5 Nov 87 17:14:26 PST
Date: Thu 5 Nov 87 17:07:50-PST
From: Thomas Dienstbier <TOM@Score.Stanford.EDU>
Subject: SUSHI MOVE
To: csd@Score.Stanford.EDU, staff@Score.Stanford.EDU,
faculty@Score.Stanford.EDU
Message-ID: <12348305470.22.TOM@Score.Stanford.EDU>
It has become time to physically move SUSHI to its new resting place in
the machine room. This is to make space available for the new VAX8700
that is due to be delivered November 24 (although not firm as of yet).
The plan is to do this move on Friday November 13, (oh oh didn't realise that)
starting at 1200 noon until finished.
tom
-------
∂06-Nov-87 0914 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Algebraic Logic and Universal Algebra in Computer Science
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Nov 87 09:14:48 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Fri 6 Nov 87 09:05:00-PST
Received: by lindy.stanford.edu; Fri, 6 Nov 87 09:07:27 PST
Received: by Forsythe.Stanford.EDU; Fri, 6 Nov 87 09:08:01 PST
Received: by NDSUVM1 (Mailer X1.24) id 3361; Fri, 06 Nov 87 10:11:39 CST
Date: 6 Nov 1987 10:57:25-EST (Friday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Cliff Bergman <S2.CHB%ISUMVS.BITNET@forsythe.stanford.edu>
Subject: Algebraic Logic and Universal Algebra in Computer Science
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
Conference Announcement
Title: Algebraic Logic and Universal Algebra in Computer
Science
Place: Iowa State University, Ames, Iowa, 50011
Dates: Wed. June 1--Sat. June 4, 1988
Focus: Algebraic Specification of Data Types
Relational Database Theory
Logic of Programs
Specification of Programming Languages
Confirmed Speakers: Joel Berman, Bjarni Jonsson, Dexter Kozen,
Istvan Nemeti, Vaughan Pratt
Information: Cliff Bergman, at the above address or
S2.CHB@ISUMVS.BITNET
∂06-Nov-87 0940 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Seminar in Applications of Logic to Computer Science
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Nov 87 09:40:43 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Fri 6 Nov 87 09:30:56-PST
Received: by lindy.stanford.edu; Fri, 6 Nov 87 08:34:03 PST
Received: by Forsythe.Stanford.EDU; Fri, 6 Nov 87 08:34:43 PST
Received: by NDSUVM1 (Mailer X1.24) id 2784; Fri, 06 Nov 87 10:07:53 CST
Date: 6 Nov 1987 10:56:55-EST (Friday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Rohit Parkih <RIPBC%CUNYVM.BITNET@forsythe.stanford.edu>
Subject: Seminar in Applications of Logic to Computer Science
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
SEMINAR IN APPLICATIONS OF LOGIC TO COMPUTER SCIENCE
This seminar meets at the City University Graduate Center, 33 W
42nd Street, New York, room 1223, Tuesdays from 11-12:30 (app). The next
meetings will be:
November 10, Stathis Zachos, Graph Isomorphism is Probably not NP-complete
November 17, Jan Plaza, More on Extensions of Kripke's Theory of Truth
∂06-Nov-87 1011 STAGER@Score.Stanford.EDU Final Exams
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Nov 87 10:11:14 PST
Date: Fri 6 Nov 87 10:05:26-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: Final Exams
To: instructors@Score.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12348490716.18.STAGER@Score.Stanford.EDU>
Time again to start reserving rooms for our final exams. Please get back to
me with the following information as soon as possible so that I can forward
our room requests/room changes on to the Room Scheduling Office:
1) Have you changed rooms since the beginning of the quarter (i.e.: moved from
your originally assigned classroom)?
2) Do you plan to give a take-home exam? Give no final exam at all?
3) Will you need additional space in order to provide alternate seating?
If so, do you require an entirely new--larger--room, or just an extra room
for overflow seating?
4) Will you be offering an alternate exam in addition to your regularly
scheduled exam? If so, please forward the new day, time, and size of room
required. (Please note that the regularly scheduled exam must be held for
any student who wishes to take it at the official exam time.)
The new University Dead Week policy, as well as the End-Quarter Examination
schedule, is printed on page 6 of the University Time Schedule for Autumn
Quarter. Please note when figuring the start time for your final exam that
"classes starting at unusual times (e.g. 2:30pm or 2:45pm) hold exams in
the same time slots as classes starting at the regular time with the same
hour designation. So, the final examination in the examples above would be
given under the 2:15pm time slot."
Please contact me with any questions or concerns.
Thanks again.
Claire
-------
∂06-Nov-87 1129 @CSLI.Stanford.EDU:barwise@russell.stanford.edu move to russell
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Nov 87 11:29:28 PST
Received: from russell.stanford.edu by CSLI.Stanford.EDU with TCP; Fri 6 Nov 87 11:22:01-PST
Received: by russell.stanford.edu (3.2/4.7); Fri, 6 Nov 87 11:20:46 PST
Date: Fri 6 Nov 87 11:20:44-PST
From: Jon Barwise <BARWISE@Russell.Stanford.EDU>
Subject: move to russell
To: ssp-faculty@russell.stanford.edu
Message-Id: <563224844.0.BARWISE@Russell.Stanford.EDU>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@Russell.Stanford.EDU>
The ssp-faculty mailing list has moved to russell. So send mail to
ssp-faculty@russell.stanford.edu.
-------
∂06-Nov-87 1130 LOGMTC-request logic seminar
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Nov 87 11:30:27 PST
Date: Fri 6 Nov 87 11:25:00-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: logic seminar
To: logmtc@Sail.Stanford.EDU
Message-ID: <12348505203.19.SF@CSLI.Stanford.EDU>
Seminar in Logic and Foundations of Mathematics
Ted Alper will finish speaking about the article by Gurevich,
"Logic tailored for computational complexity" on Mon. Nov.9
at 4:15 in Room 381-T, Mathematics, Stanford.
S.Feferman
-------
∂06-Nov-87 1802 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU SUNRISE CLUB MEETS MONDAY, NOV. 16
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Nov 87 18:02:32 PST
Received: from Tenaya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 6 Nov 87 17:55:56-PST
Received: by Tenaya.Stanford.EDU (3.2/SMI-3.2)
id AA12111; Fri, 6 Nov 87 19:27:19 PST
Date: Fri, 6 Nov 87 19:27:19 PST
From: nilsson@Tenaya.Stanford.EDU (Nils Nilsson)
Message-Id: <8711070327.AA12111@Tenaya.Stanford.EDU>
To: TAJNAI@Score.Stanford.EDU
Cc: faculty@Score.Stanford.EDU
In-Reply-To: Carolyn Tajnai's message of Thu 5 Nov 87 14:41:00-PST <12348278740.42.TAJNAI@Score.Stanford.EDU>
Subject: SUNRISE CLUB MEETS MONDAY, NOV. 16
Carolyn, Can you pls let the powers that be know that I
will be at a NASA conference on Monday morning and thus cannot
attend the sunrise bkfst. I trust you can deal with having
George Wheaton attend and introduce him around? Maybe you can
see if some other senior faculty member could be persuaded to
attend. Anne, if you see this msg, can you let my students
know that they are invited? Thanks, -Nils
∂07-Nov-87 1125 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talks
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Nov 87 11:24:57 PST
Date: Sat 7 Nov 87 11:16:18-PST
From: Anil R. Gangolli <GANGOLLI@Sushi.Stanford.EDU>
Subject: Upcoming AFLB Talks
To: aflb.all@Sushi.Stanford.EDU
Office Phone: (415) 723-3605
Message-ID: <12348765761.18.GANGOLLI@Sushi.Stanford.EDU>
PLEASE NOTE THE FOLLOWING:
* This week, BATS takes place Thursday at Berkeley, so the AFLB talk
will take place on Friday, Nov. 13, at 10:30am.
* Next week we have TWO talks. One on Tuesday, Nov. 17 and one
on Thursday, Nov 19.
THIS WEEK'S TALK:
13-November-87: Anton Dahbura (AT&T Bell Labs, Murray Hill)
Optimization Techniques for Testing Finite-State Automata
In this talk, methods are discussed for checking that a
black-box implementation of a finite-state automaton is
functionally equivalent to its specification. This problem,
known as design checking, or testing, is a special case of
the well-known machine distinguishability problem studied
for over thirty years. The design checking problem has
become increasingly important in communications network
design for testing the conformance of a network layer proto-
col to its specification. It has been shown recently by the
author that under certain conditions, optimization tech-
niques can be used to design highly effective test sequences
for testing a protocol which is modeled as an FSA. Tech-
niques for extending these techniques under less ideal con-
ditions are considered and some open problems are presented.
***** Time and place: Fri, November 13, 10:30am in MJH 352 (Bldg. 460)
********* NOTE UNUSUAL DAY AND TIME **********
NEXT WEEK'S TALKS:
17-November-87: Larry J. Stockmeyer (IBM Almaden)
Interactive Proof Systems
With Finite State Verifiers
An Interactive Proof System (IPS) for membership in a language L is a
two-party protocol whereby a ``prover'' can convince a ``verifier''
that elements x are in L. Both the prover and the verifier may make
random moves (flip coins).
To date, almost all research in interactive proof systems has dealt
with the case that the verifier is a probabilistic Turing machine
(ptm) which runs in polynomial time. Several classes of interactive
proof systems have been defined, for example, (1) the verifier may
employ either public coins or private coins, defined according to
whether the prover can see the outcomes of the random choices made by
the verifier; (2) the IPS may or may not be zero-knowledge, meaning,
roughly speaking, that no verifier can extract any information from
the interactive proof that x is in L except for the fact that x is in
L. Many previous results for ptm verifiers depend on unproved
assumptions.
By restricting attention to verifiers which are 2-way probabilistic
finite state automata (2pfa's), we obtain results about IPS's without
unproved assumptions. This talk will focus on three results: (1)
private coins are more powerful than public coins; (2) IPS's with
public coins are more powerful than 2pfa's alone; (3) there is a
language with an IPS but with no zero knowledge IPS.
(This is joint work with Cynthia Dwork who will speak at the Nov. 12
BATS on this work. Different material will be emphasized in the two
talks.)
***** Time and place: Tue, November 17, 12:30pm in MJH 352 (Bldg. 460)
********* NOTE UNUSUAL DAY **********
19-November-87: Valerie King (Berkeley)
"Lower Bounds on the Complexity of Graph Properties"
In this simple model, a decision tree algorithm must determine whether an
unknown graph on nodes {1,2,...,n} has a given property by asking questions
of the form "Is edge {i,j} in the graph?". The complexity of a property is
the number of questions which must be asked in the worst case. A property is
called evasive if its complexity is equal to the number of edges in the
complete graph.
In 1973, Aanderaa and Rosenberg conjectured that any property which is a
graph or digraph property (invariant under graph isomorphism) and is monotone
(not destroyed by the deletion of edges) and nontrivial (holds for some but
not all graphs) has complexity at least c n↑2 where n is the number of nodes
and c is a constant. This conjecture was proved by Rivest and Vuillemin who
found a constant of 1/16.
In 1984, Kahn, Saks, and Sturtevant discovered that algebraic topology could be used to prove evasiveness when n is a prime power. A consequence of this was
a lower bound of almost 1/4 n↑2 for graph and digraph properties and general
n. Recently, their technique was used to prove evasiveness for all monotone,
nontrivial bipartite graph properties (Yao, 1987) and a further improvement on
the Aanderaa-Rosenberg constant, to almost 1/2 n↑2 for all monotone nontrivial
digraph properties (King, 1987).
This talk will describe the method developed by KSS and its new applications.
***** Time and place: Thu, November 19, 12:30pm in MJH 352 (Bldg. 460)
-------
∂08-Nov-87 2031 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com REMINDER -- Monday PLANLUNCH -- Anand Rao
Received: from WARBUCKS.AI.SRI.COM by SAIL.STANFORD.EDU with TCP; 8 Nov 87 20:30:51 PST
Received: from venice by WARBUCKS.AI.SRI.COM via SMTP with TCP; Sun,
8 Nov 87 20:13:54-PST
Received: by venice (3.2/4.16) id AA26192 for
planlunch_reminder@WARBUCKS.ai.sri.com; Sun, 8 Nov 87 20:17:38 PST
Date: Sun 8 Nov 87 20:17:36-PST
From: Amy Lansky <LANSKY@venice.ai.sri.com>
Subject: REMINDER -- Monday PLANLUNCH -- Anand Rao
To: planlunch_reminder@WARBUCKS.ai.sri.com
Message-Id: <563429856.0.LANSKY@VENICE.ARPA>
Mail-System-Version: <SUN-MM(213)+TOPSLIB(128)@VENICE.ARPA>
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
EVOLVING KNOWLEDGE AND TMS
Anand S. Rao (ANAND@IBM.COM)
IBM T.J. Watson Research Center and Sydney University
(joint work with
Normal Y. Foo
IBM Systems Research Education Center and Sydney University)
11:00 AM, MONDAY, November 9
SRI International, Building E, Room EJ228
The traditional view of knowledge in the AI literature has been that
'Knowledge' is 'true belief'. The semantic account of this notion
suffers from a major problem called Logical Omniscience, where the
agent knows all valid formulas and his knowledge is closed under
implication. In this talk we propose an alternative viewpoint where
knowledge or EVOLVING KNOWLEDGE (as we call it) is treated as
'indefeasibly justified true belief'. This notion of knowledge solves
the problem of logical omniscience and also captures the
resource-bounded reasoning of agents in a natural way. We give the
semantics and axiomatization of this logic of evolving knowledge and
discuss its properties.
The logic of evolving knowledge also serves as the logical foundation
for the Truth Maintenance System (TMS). We provide a transformation to
and from TMS nodes to formulas in this logic. We show that a set of
nodes has a 'well founded labelling' iff their corresponding IN nodes
are 'satisfiable' in this logic and their corresponding OUT nodes are
'not satisfiable' in this logic. We conclude the talk by comparing our
logic with Autoepistemic Logic, Deduction model of Belief and the
Awareness model of belief.
-------
∂09-Nov-87 0205 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #85
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Nov 87 02:05:23 PST
Date: Sun 8 Nov 1987 07:41-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #85
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Monday, 9 Nov 1987 Volume 5 : Issue 85
Today's Topics:
Query - Side Effects & Intelligent Backtracking,
Implementation - Style & Badness & Machines
----------------------------------------------------------------------
Date: 4 Nov 87 06:49:46 GMT
From: munnari!mulga!jayen@uunet.uu.net (Jayen Vaghani)
Subject: Preserving side-effects in Intelligent backtracking
I am currently completing a project on preserving side-effects in
intelligent backtracking and are currently implementing the algorithm
in a full Prolog system. The intelligent backtracking method we are
using is one similar to the B-list scheme of Kumar and Lin. I would be
interested in hearing from any other people who are looking at the
same area, and what sort of results they have come up with.
Thank you.
-- Jayen
------------------------------
Date: Thu, 05 Nov 87 16:57:01 +1100
From: Jeff Schultz <munnari!mulga.oz.au!jws@uunet.UU.NET>
Subject: Programming Style
John Cugini asks how to re-write cleanly the ancestor relation so that
it runs whether it is the ancestor or the descendent argument that is
known.
His original code
ancestor_descendant(Anc, Des) :- parent_child(Anc, Des).
ancestor_descendant(Anc, Des) :-
parent_child(Anc, Middle),
ancestor_descendant(Middle, Des).
is fine for finding descendents, but performs a blind search for
ancestors. One can write a similar predicate with the opposite
problem:
descendant_ancestor(Des, Anc) :- parent_child(Anc, Des).
descendant_ancestor(Des, Anc) :-
parent_child(Middle, Des),
descendant_ancestor(Middle, Anc).
One way to get behaviour independent of instantiation pattern
is to use both of these. For example
ad(Anc, Des) :-
(var(Anc) ->
descendant_ancestor(Des, Anc)
; ancestor_descendant(Anc, Des)
).
A cleaner,though less efficient, solution is possible with a Prolog
capable of delaying goals until some suitable combination of their
arguments is instantiated. In NU-Prolog, the following would work
?- ancestor_descendant(Anc, _) when Anc.
?- descendant_ancestor(Des, _) when Des.
ad(Anc, Des) :-
ancestor_descendant(Anc, Des),
descendant_ancestor(Des, Anc).
Whichever version is sufficiently instantiated runs first with the
other verifying the answer afterwards. The amount of work saved over
using ancestor_descendant/2 depends on the nature of the parent_child/2
relation. The worst case is when everyone is related.
As another example, the NU-Prolog code for length/2
?- length(A, B) when A or B.
length([], 0).
length(_.L, N) :-
N > 0,
plus(N1, 1, N),
length(L, N1).
also runs in either direction. (Plus/3 waits for any two of its
arguments, and then computes the remaining one so that Z = X + Y.)
------------------------------
Date: Fri, 6 Nov 87 11:46:09 +0100
From: "Micha Meier" <unido!ecrcvax!micha@uunet.UU.NET>
Subject: Programming Style
The question is, whether
ancestor_descendant(Anc, Des) :- parent_child(Anc, Des).
ancestor_descendant(Anc, Des) :-
parent_child(Anc, Middle),
ancestor_descendant(Middle, Des).
can be executed efficiently and cleanly.
Although the problems mentioned by John Cugini are solved by query
optimizations in the database area, there is as well a clean Prolog way
to handle them, but it requires extensions to Prolog. What is required
here is to change the depth-first, left-to-right Prolog search
depending on the instantiation of the arguments in the call.
Suspending a call which is not instantiated enough is a clean
and easy solution. A solution could be simulated even with the freeze/2
primitive of Prolog II, however other Prolog dialects provide
more sophisticated mechanisms - wait declaration in MU-Prolog
and ECRC-Prolog, when declarations in NU-Prolog, delay declarations
in Sepia etc.
In our new system, Sepia, I would add the following:
?- delay parent_child(Anc, Des) if var(Anc) & var(Des).
which means exactly what it says - the call to parent_child/2 will
be delayed if both arguments are variables and it will be resumed
if one of the arguments is instantiated or if there is nothing else
to execute.
The 'delay' clause is in fact a metaclause which specifies a certain
control for the procedure. In such a way metalogical predicates
need not be included in the program itself, they are present
in metaclauses only.
Although there are not many Prolog systems available that
support predicate delaying, it is clear that their importance
will grow - they can handle database applications, constraints
propagation, increase efficiency, improve backtracking behavior
so that intelligent backtraking follows automatically, infinite
loops and many more. At the same time, the implementation can
be so efficient that the speed of non-delaying execution
is not visibly affected (we still make 200kLIPS with Sepia
on the 25MHz SUN-3).
------------------------------
Date: Wed, 4 Nov 87 16:48:20 EST
From: blenko@burdvax.PRC.Unisys.COM (Tom Blenko)
Subject: Badness
I'm not certain Richard's posting was really a question, but I promise
the following will be brief (well, sort of).
I think the answer to his question is simple enough. Most code, Prolog
and otherwise, is good enough because it runs. Programmers have
neither the time nor the interest to engage in the pensive, reflective
approach to programming that O'Keefe espouses. Lest anyone take this
as a denigration of "industrial quality" software development, my
experience has been that academics write significantly worse software
(by Richard's measure) than professional programmers. Which is
fine, because academics often have other more important things to
occupy themselves with.
So the answer, in a nutshell, is that goodness (and even correctness)
of software depends upon one's perspective. And the overwhelming
majority of those writing software do not share Richard's perspective.
Professional software developers can, and sometimes do, expend
additional time and effort when they determine it is necessary to
produce more "correct" software (although, of course, they are not
always successful).
My favorite bit of erroneous Prolog software is the oft-cited append()
procedure/relation:
append([],X,X).
append([H|T1],X,[H|T2]) :-
append(T1,X,T2).
I don't believe I've ever seen the incorrectness (by Richard's view)
acknowledged in a text or publication, nor have I seen a correct
version (even in the Quintus library!). The problem, of course, is
illustrated by the fact that cons() may be defined in terms of
append():
cons(A,B,C) :-
append([A],B,C).
My claim is that the definition of append() above has been acceptable
to Prolog programmers for the same reason that most erroneous code is
acceptable to other programmers: it runs correctly enough for the task
at hand, and (in this case) significantly faster than a correct
implementation would.
In response to Richard's observations about the quality of Prolog code
as an instance of a more general phenomenon, and more in keeping with
the issue I suppose he intended to raise, I propose that bad Prolog
code is in many cases likely to be worse than bad Pascal or C code for
these reasons:
1. It is almost never the case that the programmer intends to
use the full generality of relational definitions.
Consequently he or she is unlikely to test for (or even take
into account) unintended uses of the software.
2. Interactions with assert() and retract() are no easier to
anticipate than the effects of assignment in imperative
languages (in fact I would guess that they are often
harder).
3. Backtracking and cut are more difficult use than more
conventional control constructs (I'd be interested if
anyone is willing to present a strong argument to the
contrary).
4. As Richard's earlier diatribe and several subsequent
messages have indicated, there are (currently) some rather
dramatic implementation-dependent pitfalls with respect to
performance (far more than one would expect to see between
and among C or Pascal implementations).
5. It is well known that O'Keefe's and Naish's exhortations
to Lagache (for sensitivity to efficiencies in the
implementation and for conformity to simple declarative
interpretations) will sometimes conflict. This presents
the programmer with a dilemma that he or she may not
(indeed may not be able to) escape.
-- Tom
------------------------------
Date: 3 Nov 87 02:27:59 GMT
From: ji.Berkeley.EDU!carlton@ucbvax.Berkeley.EDU (Mike Carlton)
Subject: Looking For Prolog Machines
Thanks for the kind words. Let me give some background on the Aquarius
project here at Berkeley. The group has built several Prolog machines to
date, beginning with an NCR 9300 based system. Prolog programs were compiled
to WAM (Warren Abstract Machine) and then to microcode. With a cycle time
of 150 ns., this system achieved 53 KLIPS for determinate concat in 1985.
The next machine, the PLM, was a TTL implementation of the WAM with some
local improvements, see [Dobry87]. The PLM was simulated to run at 400 KLIPS
for determinate concat, based on a 100 ns. cycle.
Another project implemented the WAM instruction set in microcode on a
VAX 8600. This machine, with an 80 ns. cycle, reached 108 KLIPS on
determinate concat.
The most recent machine (chip actually) is the VLSI PLM, being fabricated
right now. This is a 200K equivalent transistor, 1.4 micron CMOS implement-
ation of an extended PLM. With a cycle time of 100 ns. this chip has been
simulated at 416 KLIPS for determinate concat and 98 KLIPS for Warren's Chat
program.
The Prolog compiler used for most of this research was written by Peter Van
Roy [VanRoy85], and is available directly from him. He can be reached via
email at vanroy@ji.berkeley.edu.
Unfortunately, the VLSI PLM is not available as a MOSIS tape as Renu's
message indicated. The chip was funded in part by NCR and they are
fabricating it for us and for their own use.
Our focus has shifted away from single processor systems; current research
centers around parallel execution Prolog machines. For some results from
recent work in this area, see [Fagin87]. Altogether, more than 50 papers
and reports have been produced by the Aquarius project. If anyone would
like a list of the publications, please send electronic mail to Kathleen
Nimr (nimr@ji.berkeley.edu). Most of these publications are still available
from her.
As for commercial products, Xenologic licensed the PLM design from the
university and has designed an improved version, called the X-1. This is a
set of 2 VME boards which plug into a Sun workstation and function as a
coprocessor. I don't have exact performance figures for their machine, but
have been told that they are better than the PLM.
Hope this helps, if you would like more information or have any questions
please send us mail,
-- Mike (and the rest of the Aquarius group)
References:
Dobry, T., "A High Performance Architecture for Prolog", Ph.D Dissertation,
UCB, May 1987
Fagin, B., Despain, A., "Performance Studies of a Parallel Prolog
Architecture", 14th ICSA, June 1987
Van Roy, P., "A Prolog Compiler for the PLM", UCB/CSD Report No. 84/203,
November 1984
Disclaimer: I have nothing to do with Xenologic (other than wanting my
own X-1 for the Sun in my office!). However, some members of our research
group do have connections with Xenologic. This should not be construed as
an advertisement for Xenologic.
------------------------------
End of PROLOG Digest
********************
∂09-Nov-87 0808 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU Tuesday 11/10 lunch
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Nov 87 08:07:58 PST
Received: from Tenaya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 9 Nov 87 08:03:19-PST
Received: by Tenaya.Stanford.EDU (3.2/SMI-3.2)
id AA13684; Mon, 9 Nov 87 08:06:50 PST
Date: Mon, 9 Nov 87 08:06:50 PST
From: nilsson@Tenaya.Stanford.EDU (Nils Nilsson)
Message-Id: <8711091606.AA13684@Tenaya.Stanford.EDU>
To: faculty@score
Subject: Tuesday 11/10 lunch
Our faculty lunch this Tuesday, Nov. 10 will discuss the
upcoming "visiting committee" visit. The following people
have consented to be on the committee and to come to Stanford
on Feb 2 and 3 to look at the department: Sam Fuller of DEC (chair),
Al Aho of ATT Bell Labs, Barbara Grosz of Harvard, Robert
Kahn of the National Research Institute, Robert Sproull of
Sutherland, Sproull Associates, and Joel Moses of MIT. I am
preparing an agenda for their visit and would like input from
the faculty.
Mike Genesereth would like to take a few minutes also to
discuss a proposed ownership/rights/licensing policy
regarding electonically recorded courseware.
12:15; MJH 146.
-Nils
∂09-Nov-87 1439 @Score.Stanford.EDU:ME@SAIL.Stanford.EDU SAIL user disk packs (UDPs) to be retired
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Nov 87 14:39:38 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 9 Nov 87 14:30:47-PST
Date: 09 Nov 87 1432 PST
From: Martin Frost <ME@SAIL.Stanford.EDU>
Subject: SAIL user disk packs (UDPs) to be retired
To: csd-list@Score.Stanford.EDU
The SAIL user disk packs (UDPs) are scheduled to be permanently retired
on 18 Dec 1987. The UDPs depend on the old disk drives, controller and
channel, which are now difficult, if not impossible, to maintain.
We are in the process of dumping most of the UDPs to SAIL Dart tapes
prior to their retirement. These tapes will still be available after
the UDPs have gone away. If you want to know whether a given UDP will
be dumped to tape, send me the name of the UDP of interest.
Also, if any SAIL UDPs contain files which you wish to keep online, please
contact me (ME@SAIL) to arrange to transfer the files to another medium.
∂09-Nov-87 1719 ALPERT@Score.Stanford.EDU FRAME MAKER publishing demo
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Nov 87 17:19:05 PST
Date: Mon 9 Nov 87 17:12:12-PST
From: Jack Alpert <ALPERT@Score.Stanford.EDU>
Subject: FRAME MAKER publishing demo
To: csd@Score.Stanford.EDU, staff@Score.Stanford.EDU,
faculty@Score.Stanford.EDU, g.gorin@Macbeth.Stanford.EDU
cc: Tom@Score.Stanford.EDU, alpert@Score.Stanford.EDU
Message-ID: <12349354841.17.ALPERT@Score.Stanford.EDU>
FRAME MAKER -- Jennifer Garrison from FRAME TECHNOLOGY will be at CSD on Monday
November 23 at 1:30 PM, rm 030 MJH to give a demonstration of "FRAME MAKER."
RSVP if you are coming to the demo.
A demo copy of Frame Maker exists on the Jeeves file server and
YOU CAN HAVE YOUR OWN COPY of the demo software. HOWEVER I have only one
Reference Manuel and User's Guide. Contact Dan Kolkowitz for software access.
INTERLEAF -- A demo copy of Interleaf which allows adding up to 5 additional
workstations has arrived and will be put up on JEEVES by Monday November 16.
If you want to have your Sun enabled. Please send your host ID to
Kolkowitz@score. This offer is limited. Alpert@score for details. I have
received one copy of the Interleaf Reference Manuals.
ARBOR TEXT -- In mid- November I will receive a copy of ARBOR TEXT. I have not
seen it but I understand it is a two window system. In one widow is an ASCII
character file with tex or latex commands and text. The other window is an
updateable preview window.
Jack Alpert 3-1096
-------
∂09-Nov-87 2206 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Marist College Colloquium Series 87-88
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Nov 87 22:06:05 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Mon 9 Nov 87 21:57:35-PST
Received: by lindy.stanford.edu; Mon, 9 Nov 87 22:00:05 PST
Received: by Forsythe.Stanford.EDU; Mon, 9 Nov 87 22:00:56 PST
Received: by NDSUVM1 (Mailer X1.24) id 4109; Mon, 09 Nov 87 17:57:08 CST
Date: 9 Nov 1987 11:44:35-EST (Monday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "William J. Joel" <JZEM%MARIST.BITNET@forsythe.stanford.edu>
Subject: Marist College Colloquium Series 87-88
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
MARIST COLLEGE
DIVISION OF COMPUTER SCIENCE & MATHEMATICS
COLLOQUIUM SERIES 87-88
*******************
POUGHKEEPSIE, NY -- All talks are held at 11:25 am in Donnelly
Hall room 245. Refreshments will be served.
Automatic Speech Recognition by Statistical Methods
Arthur Nadas
IBM T.J. Watson Research Center
November 13, 1987
A research team led by Dr. Frederick Jelinek at the IBM
T.J.Watson Research Center in Yorktown Heights has built a real-
time, large vocabulary automatic speech recognition system for
dictation of office correspondence. This system is by far the
best of its kind known today. The talk will sketch the organiza-
tion of this system and the basic statistical ideas used in its
construction. The talk will conclude with a short videotape pres-
entation of a demonstration using a PC based version of the ASR
system.
Arthur Nadas was born in Budapest in 1934. He received the
B.A. degree in mathematics from Alfred University in 1959 and
the M.A. degree in mathematics from the University of Oregon in
1961. He was an IBM Graduate Fellow at Columbia University where
in 1967 he received the Ph.D. degree in mathematical statistics.
Dr. Nadas joined the IBM Corporation in 1961 at the Product
Testing Laboratory in Poughkeepsie. Since then he has worked in a
variety of areas including process control, reliability, proces-
sor design, signal processing, speech recognition and others. He
has taught mathematics and statistics at the Polytechnic Insti-
tute of New York, The State University of New York, IBM's System
Research Institute and in other IBM educational programs at Fish-
kill, Kingston, Poughkeepsie and Yorktown Heights. He is the
author of a number of papers in mathematics and statistics, sev-
eral patent disclosures and he has received a patent for a sta-
tistical algorithm used in speech recognition. His work in the
automatic statistical characterization of speech sounds earned
him an IBM Outstanding Technical Achievement Award. He is a mem-
ber of several professional societies and is a past president of
the American Statistical Association's Mid-Hudson chapter. At
this time he is working in computer science and mathematics as a
Research Staff Member at the IBM T.J. Watson Research Center,
Yorktown Heights, NY, 10598.
*******************
∂10-Nov-87 0115 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for Papers, ACM Computational Geometry Symposium
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 10 Nov 87 01:15:34 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 10 Nov 87 01:08:45-PST
Received: by lindy.stanford.edu; Tue, 10 Nov 87 01:11:26 PST
Received: by Forsythe.Stanford.EDU; Tue, 10 Nov 87 01:11:56 PST
Received: by NDSUVM1 (Mailer X1.24) id 8413; Mon, 09 Nov 87 20:56:31 CST
Date: 9 Nov 1987 21:48:35-EST (Monday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMZ
From: Bernard Chazelle <PRINCETON!NOTECNIRP!CHAZELLE%RUTGERS.EDU@forsythe.stanford.edu>
Subject: Call for Papers, ACM Computational Geometry Symposium
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
CALL FOR PAPERS
Fourth Annual ACM Symposium on
COMPUTATIONAL GEOMETRY
6-8 June 1988
University of Illinois
Urbana-Champaign, Illinois
Papers presenting original research in
computational geometry are being sought. Suggested
topic areas include (but are not limited to):
* design and analysis of geometric algorithms
* data structures for computational geometry
* applications with a geometric flavor, including
-- robotics: collision avoidance, motion planning
-- computer graphics: hidden surface and rendering algorithms
-- solid modeling and freeform surface modeling
-- pattern recognition: shape decomposition
* mathematical bases for computational geometry
* issues arising from the implementation of geometric algorithms
* programming language issues in computational geometry
Authors should send eleven (11) copies of an extended abstract
by December 15, 1987 to the Program Committee Chair:
Bernard Chazelle
Department of Computer Science
Princeton University
Princeton, NJ 08544
Late submissions risk rejection without further consideration.
Authors will be notified of acceptance or rejection by February
9, 1988. A copy of each accepted paper, typed on model paper, will be due
by March 16, 1988, for inclusion in the proceedings.
Authors are advised to prepare their extended abstracts carefully.
Each submission should begin with a succinct
statement of the problems, the main results, and the
significance of the work in the context of previous research.
The extended abstract (not a full paper)
should provide sufficient detail
to allow the program committee to evaluate the quality of the
contribution and its appropriateness to the
conference. The entire extended abstract should not exceed
10 double-spaced pages.
The Symposium is sponsored by ACM SIGACT and SIGGRAPH. Proceedings
will be distributed at the Symposium and will be subsequently available
for purchase from ACM.
Symposium Committees
Program Committee Conference Chair
Chanderjit Bajaj V. Thomas Rajan Herbert Edelsbrunner
Bernard Chazelle Richard Riesenfeld Department of Computer Science
Patrick Hanrahan Raimund Seidel University of Illinois
David Kirkpatrick Robert Tarjan 1304 West Springfield Ave.
Kurt Mehlhorn Christopher Van Wyk Urbana, IL 61801
Richard Pollack
∂10-Nov-87 0816 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu undecidability of system of first order predicates
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 10 Nov 87 08:16:02 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 10 Nov 87 08:06:39-PST
Received: by lindy.stanford.edu; Tue, 10 Nov 87 08:09:19 PST
Received: by Forsythe.Stanford.EDU; Tue, 10 Nov 87 08:10:13 PST
Received: by NDSUVM1 (Mailer X1.24) id 5749; Tue, 10 Nov 87 09:33:48 CST
Date: 10 Nov 1987 10:11:33-EST (Tuesday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Lim Eng-Liam <ISCLIMEL%NUSVM.BITNET@forsythe.stanford.edu>
Subject: undecidability of system of first order predicates
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
Hello,
I am a CS student with one course for each of these subjects: logic
(using Llyod & Kowalski & some papers), formal theory and computability
(Hopcroft &Ullman, Garey & Johnson).
I will be glad to receive any information on works either ongoing
or completed on restrictions that are placed on the forms of predicates
so that the checking of consistency of such systems becomes decidable.
Examples of such attempt could be the restriction on the system to
contain only monadic predicates or the elimination of recursive
definitions. However, these do not appear to allow for easy description
of the world. I am hoping for a less tight constraint.
Please write to me if you know of any interesting results and proofs.
Deepest appreciation !
Best regards,
Lim Eng-Lian
∂10-Nov-87 0904 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU Associate Chairman
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 10 Nov 87 09:04:11 PST
Received: from Tenaya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 10 Nov 87 08:54:06-PST
Received: by Tenaya.Stanford.EDU (3.2/SMI-3.2)
id AA14836; Tue, 10 Nov 87 08:57:38 PST
Date: Tue, 10 Nov 87 08:57:38 PST
From: nilsson@Tenaya.Stanford.EDU (Nils Nilsson)
Message-Id: <8711101657.AA14836@Tenaya.Stanford.EDU>
To: csd.list@score, faculty@score, xcomx@sierra
Subject: Associate Chairman
For the past few weeks some of the faculty and I have been
interviewing candidates to help me with some of the administrative
burdens of running the Computer Science Department. We have found an
excellent person for this job----George Wheaton. He will be joining
us as Associate Chairman effective Monday, November 16, 1987. George
comes to us with many years of managerial experience in high-tech
companies and start-up firms. He received his B.S. from Stanford in
Civil Engineering (about the same time I was an undergraduate at
Stanford) and an M.B.A. from Harvard.
Our administrative set-up will be as follows. Betty Scott, our
administrative officer, will continue to report to me and will be in
charge of all external and internal accts., student research
assistantships, publications, faculty matters (visas and all the other
things she has been doing wo well to help the faculty). Stuart Reges,
Asst. Chairman for Education, continues in that position---reporting
to me. Carolyn Tajnai, Asst. Chairperson for External Relations,
continues in that position---reporting to me. Jim Ball, CSD-CF
Director, Yvette Sloan, Resources Administrator, and Sharon Hemenway,
Graduate Programs Administrator, continue in their present positions
but will report to George Wheaton.
I want to give special thanks to Betty, Stuart, Carolyn, Jim, Yvette,
and Sharon for their support and hard work during this process of
making some changes to the organization of the department. Betty, the
person who has been here the longest---and has seen department chairs
come and go (and reorganize), has been very understanding and, as
usual, devoted to the department.
Also thanks to Les Earnest, who has been a great help as a part-time
Assoc Chair and will now be able to return to research matters full
time.
I am very glad that George will be joining us and wish him many years
of rewarding experience at Stanford. Please join me in welcoming him
to the department.
-Nils
∂10-Nov-87 0917 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU Wheaton
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 10 Nov 87 09:17:18 PST
Received: from Tenaya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 10 Nov 87 08:56:11-PST
Received: by Tenaya.Stanford.EDU (3.2/SMI-3.2)
id AA14841; Tue, 10 Nov 87 08:59:44 PST
Date: Tue, 10 Nov 87 08:59:44 PST
From: nilsson@Tenaya.Stanford.EDU (Nils Nilsson)
Message-Id: <8711101659.AA14841@Tenaya.Stanford.EDU>
To: faculty@score
Subject: Wheaton
I'll be introducing our new Associate Chair, George Wheaton,
at the faculty lunch today. MJH 146; 12:15. -Nils
∂10-Nov-87 1504 @Score.Stanford.EDU:RINDFLEISCH@SUMEX-AIM.STANFORD.EDU SPO Advisory Committee
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 10 Nov 87 15:03:58 PST
Received: from SUMEX-AIM.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Tue 10 Nov 87 14:58:28-PST
Date: Tue, 10 Nov 87 15:02:21 PST
From: TC Rindfleisch <Rindfleisch@SUMEX-AIM.STANFORD.EDU>
Subject: SPO Advisory Committee
To: KSL-Exec@SUMEX-AIM.STANFORD.EDU, Faculty@SCORE.STANFORD.EDU,
SrStaff@SCORE.STANFORD.EDU, KSL-Admin@SUMEX-AIM.STANFORD.EDU,
Keep@SUMEX-AIM.STANFORD.EDU
cc: Rindfleisch@SUMEX-AIM.STANFORD.EDU
Message-ID: <12349593344.22.RINDFLEISCH@SUMEX-AIM.STANFORD.EDU>
When Fred Bentley was appointed permanent head of SPO early this year, it was
agreed that an oversight committee would be set up to try to make SPO more
responsive to university needs. That committee is finally getting off the
ground and I've been asked to serve on it. The first meeting is Friday, 11/20.
If you have concerns about SPO or recommendations about how to increase their
effectiveness, please let me know asap. An EMail message to
Rindfleisch@SUMEX-AIM is preferred or if you want to talk by phone, call
723-5569.
Tom R.
-------
∂10-Nov-87 1520 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU re: SPO Advisory Committee
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 10 Nov 87 15:20:37 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 10 Nov 87 15:14:15-PST
Date: 10 Nov 87 1517 PST
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: re: SPO Advisory Committee
To: Rindfleisch@SUMEX-AIM.STANFORD.EDU,
KSL-Exec@SUMEX-AIM.STANFORD.EDU,
Faculty@Score.Stanford.EDU,
SrStaff@Score.Stanford.EDU, KSL-Admin@SUMEX-AIM.STANFORD.EDU,
Keep@SUMEX-AIM.STANFORD.EDU
CC: Rindfleisch@SUMEX-AIM.STANFORD.EDU
[In reply to message from Rindfleisch@SUMEX-AIM.STANFORD.EDU sent Tue, 10 Nov 87 15:02:21 PST.]
I am at a loss to respond, because I don't know exactly what SPO does.
When you know, perhaps you could send this list a message outlining what
it is and what are the issues. By the way it isn't clear to me whether
Senior Research Associates are on your list; they should be. One further
remark. When a bureaucrat is contemplating how to enlarge his empire,
an excellent strategy is to ask the public his empire serves to think
up new things it could do. Responsiveness to public needs then justifies
requests for more staff. The Advisory Committee should also be alert
to the possibility of finding some of what SPO does to be unnecessary.
∂10-Nov-87 2000 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu NSPACE
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 10 Nov 87 19:59:59 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 10 Nov 87 19:52:22-PST
Received: by lindy.stanford.edu; Tue, 10 Nov 87 19:55:07 PST
Received: by Forsythe.Stanford.EDU; Tue, 10 Nov 87 19:55:52 PST
Received: by NDSUVM1 (Mailer X1.24) id 7208; Tue, 10 Nov 87 20:58:59 CST
Date: 10 Nov 1987 18:08:04-EST (Tuesday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Paul Vitanyi <MCVAX!CWI.NL!PAULV@uunet.uu.net>
Subject: NSPACE
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
In the EATCS Bulletin of October 1987 (Number 33), pp. 94-100,
there is an article by Robert Szelepcsenyi ``The method
of forcing for nondeterministic automata'', claiming
the result
NSPACE (L(n)) is closed under complement for L(n) >= log n
The author refers to an earlier tech rept (in Slovak):
``R. Szelepcsenyi, Context-sensitive languages are closed
under complementation, Tech. rept. Komensky University,
April 87.
The author does not refer Neil Immerman.
∂10-Nov-87 2037 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: undecidability of system of first order predicates
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 10 Nov 87 20:36:58 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 10 Nov 87 20:30:31-PST
Received: by lindy.stanford.edu; Tue, 10 Nov 87 20:33:13 PST
Received: by Forsythe.Stanford.EDU; Tue, 10 Nov 87 20:33:56 PST
Received: by NDSUVM1 (Mailer X1.24) id 8114; Tue, 10 Nov 87 21:14:28 CST
Date: 10 Nov 1987 18:08:12-EST (Tuesday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Vaughan Pratt <CORAKI!PRATT@sun.com>
Subject: Re: undecidability of system of first order predicates
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
One particularly large theory is "all" of programming logic restricted
to decidable data theories (a la Nelson-Oppen) and no binding
mechanisms (assignment statements, quantifiers, and recursive
procedure definitions) Programming logic includes first order logic,
partial correctness/termination/equivalence of programs, regular
control structures (if/while/compound-statements), and theories of
various data types: lists, integers, sets, arrays (as either
"first-class" or "second-class" citizens), etc. The restriction to
decidable data theories forbids the combination of integer addition and
multiplication in the same theory (undecidability of Hilbert's 10th
problem means that even the quantifier-free fragment of this theory is
undecidable) and certain other theories, but still admits a very large
number of other useful theories. Procedure calls are OK, with
parameters passed by value, it is just the recursive procedure
definitions that cannot show up in the logic.
The relevant reference is
Pratt, V.R., "Program Logic Without Binding is Decidable", Proc. 8th
Ann. ACM Symposium on Principles of Programming Languages, January,
1981, 159-163.
Even such a large theory however cannot be regarded as adequately
"describing the world." Otherwise you could formulate questions like
"Will there be an even number of World Wars?" for which a decision
method seems unlikely. You need a less ambitious (or better defined)
goal.
∂10-Nov-87 2131 LOGMTC-request logic seminar
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 10 Nov 87 21:31:09 PST
Date: Tue 10 Nov 87 21:29:18-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: logic seminar
To: logmtc@Sail.Stanford.EDU
Message-ID: <12349663786.12.SF@CSLI.Stanford.EDU>
Seminar in Logic and the Foundations of Mathematics
Ted Alper will complete his presentation of the Gurevich paper and
Phokion Kolaitis will start talking about some work of Immerman's
about global inductive definitions on finite structures.
Mon. Nov. 16, 4:15-5:30 PM, 381T, Stanford Mathematics Bldg.
S. Feferman
-------
∂11-Nov-87 0938 TAJNAI@Score.Stanford.EDU Please RSVP for Sunrise Club Breakfast
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Nov 87 09:38:15 PST
Date: Wed 11 Nov 87 09:33:26-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Please RSVP for Sunrise Club Breakfast
To: faculty@Score.Stanford.EDU
Message-ID: <12349795611.16.TAJNAI@Score.Stanford.EDU>
Joe Goodman, new chairman of EE, will be the speaker.
7:30 a.m., Monday, Nov. 16, Tresidder.
SOE needs rsvps.
Carolyn
-------
∂11-Nov-87 1028 TAJNAI@Score.Stanford.EDU Nils' Newsletter to Alumni and Friends of the Dept.
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Nov 87 10:28:29 PST
Date: Wed 11 Nov 87 10:23:15-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Nils' Newsletter to Alumni and Friends of the Dept.
To: faculty@Score.Stanford.EDU
Message-ID: <12349804682.16.TAJNAI@Score.Stanford.EDU>
Our new CSD brochure should be published by Dec. 1, and we want to
mail it with a Newsletter to alumni and friends.
If you wish to contribute a paragraph to the letter, please send it to
me.
Monday, Nov. 23 deadline.
Carolyn
-------
∂11-Nov-87 1648 EMMA@CSLI.Stanford.EDU CSLI Calendar delayed
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Nov 87 16:47:46 PST
Date: Wed 11 Nov 87 16:11:40-PST
From: Emma Pease <Emma@CSLI.Stanford.EDU>
Subject: CSLI Calendar delayed
To: friends@CSLI.Stanford.EDU
Reply-To: emma@russell.stanford.edu
Tel: (415) 723-3561
Message-ID: <12349868108.21.EMMA@CSLI.Stanford.EDU>
The CSLI Calendar will be sent out tomorrow.
I am moving the mailing list for the CSLI Calendar to a different
machine and changing the format slightly. It is possible that a few
names may drop off the list accidently; if you do not receive a
calendar by Monday, please send me a note.
Emma Pease
Emma@russell.stanford.edu
ps. There is no TINLunch or seminar tomorrow.
-------
∂11-Nov-87 1713 X3J13-mailer Final reservations
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Nov 87 17:13:02 PST
Received: from hplabs.HP.COM (hplabs.hpl.hp.com.#Internet) by SCORE.STANFORD.EDU with TCP; Wed 11 Nov 87 17:08:57-PST
Received: from hpfcla.HP.COM (hpfcla) by hplabs.HP.COM with SMTP ; Wed, 11 Nov 87 17:12:18 PST
Received: from hpfclp.HP.COM by hpfcla.HP.COM; Wed, 11 Nov 87 17:58:16 mst
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Wed, 11 Nov 87 17:57:42 mst
Received: from hpfcdcm by hpfcdcm.HP.COM; Wed, 11 Nov 87 17:57:43 mst
Return-Path: <dcm@hpfcdcm>
To: x3j13@sail.stanford.edu
Cc: mathis@ADA20.ISI.EDU
Subject: Final reservations
From: Dave_Matthews%hpfclp@hplabs.HP.COM
X-Mailer: mh6.5
Date: Wed, 11 Nov 87 17:57:40 MST
Message-Id: <1830.563677060@hpfcdcm>
Sender: dcm%hpfclp@hplabs.HP.COM
I've scheduled two conference rooms for Monday afternoon for
subcommittee meetings - one for the cleanup committee and one for
the character committee. They will be available all afternoon.
This is the latest list of registrants and dinner guests that I
have. If you aren't listed, such as Bob Mathis, and plan to
attend, please give me a call.
I've eliminated the chicken and salmon as a result of low demand
and added a new dinner choice column to the list of registrants.
Please call me if you have ????? for your dinner selection as you
will need to choose something else.
If you have any questions or need additional help call me and
leave a detailed message if I'm not available. I'll try to get
back to you ASAP.
Dave Matthews
303-229-2201
Peter Coffee Aerospace Corporation -
Jim O'Dell Alliant Computer sirloin
Kathy Chapman Digital Equipment Corporation veg
Walter van Roggen Digital Equipment Corporation duck
Dan Pierson Encore Computer Corporation duck
Sandra Loosemore Evans & Sutherland Computer Corp. shrimp
Steve Haflich Franz Inc. ??????
Kevin Layer Franz Inc. sirloin
Richard Greenblat GigaMOS Systems, Inc. sirloin
Jeff Rosenking Grumman Corporation shrimp
Paul Beiser Hewlett Packard Company shrimp
James Kempf Hewlett Packard Company duck
Dave Matthews Hewlett Packard Company lamb
George Hadden Honeywell shrimp
Aaron Larson Honeywell shrimp
Thom Linden IBM shrimp
Mary Van Deusen IBM duck
Greg Nuyens ILOG S.A. duck
Jerome Chailloux INRIA/ILOG duck
Mary Boelk Johnson Controls, Inc. shrimp
Dick Gabriel Lucid, Inc. sirloin
JonL White Lucid, Inc. lamb
Jan Zubkoff Lucid, Inc. duck
Linda DeMichiel Lucid, Inc. lamb
David Loeffler MCC sirloin
Christopher Dabrowski National Bureau of Standards -
Eric Schoen Schlumberger Palo Alto Research -
Chris Perdue Sun Microsystems duck
Sonya Keene Symbolics, Inc. sirloin
Bob Kerns Symbolics, Inc. ??????
David Moon Symbolics, Inc. -
Kent Pitman Symbolics, Inc. duck
Will Clinger Tektronix Laboratories -
David Bartley Texas Instruments lamb
Patrick Dussud Texas Instruments -
Ellen Waldrum Texas Instruments shrimp
Guy Steele Thinking Machines Corporation shrimp
Thomas Turba Unisys Corp. shrimp
Julian Padget University of Bath duck
Jeff Dalton University of Edinburgh sirloin
Daniel Bobrow Xerox Corporation lamb
Pavel Curtis Xerox Corporation lamb
Andy Daniels Xerox Corporation lamb
Gregor Kiczales Xerox Corporation duck
Larry Masinter Xerox Corporation shrimp
∂11-Nov-87 1800 X3J13-mailer Final reservations
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Nov 87 17:13:02 PST
Received: from hplabs.HP.COM (hplabs.hpl.hp.com.#Internet) by SCORE.STANFORD.EDU with TCP; Wed 11 Nov 87 17:08:57-PST
Received: from hpfcla.HP.COM (hpfcla) by hplabs.HP.COM with SMTP ; Wed, 11 Nov 87 17:12:18 PST
Received: from hpfclp.HP.COM by hpfcla.HP.COM; Wed, 11 Nov 87 17:58:16 mst
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Wed, 11 Nov 87 17:57:42 mst
Received: from hpfcdcm by hpfcdcm.HP.COM; Wed, 11 Nov 87 17:57:43 mst
Return-Path: <dcm@hpfcdcm>
To: x3j13@sail.stanford.edu
Cc: mathis@ADA20.ISI.EDU
Subject: Final reservations
From: Dave_Matthews%hpfclp@hplabs.HP.COM
X-Mailer: mh6.5
Date: Wed, 11 Nov 87 17:57:40 MST
Message-Id: <1830.563677060@hpfcdcm>
Sender: dcm%hpfclp@hplabs.HP.COM
I've scheduled two conference rooms for Monday afternoon for
subcommittee meetings - one for the cleanup committee and one for
the character committee. They will be available all afternoon.
This is the latest list of registrants and dinner guests that I
have. If you aren't listed, such as Bob Mathis, and plan to
attend, please give me a call.
I've eliminated the chicken and salmon as a result of low demand
and added a new dinner choice column to the list of registrants.
Please call me if you have ????? for your dinner selection as you
will need to choose something else.
If you have any questions or need additional help call me and
leave a detailed message if I'm not available. I'll try to get
back to you ASAP.
Dave Matthews
303-229-2201
Peter Coffee Aerospace Corporation -
Jim O'Dell Alliant Computer sirloin
Kathy Chapman Digital Equipment Corporation veg
Walter van Roggen Digital Equipment Corporation duck
Dan Pierson Encore Computer Corporation duck
Sandra Loosemore Evans & Sutherland Computer Corp. shrimp
Steve Haflich Franz Inc. ??????
Kevin Layer Franz Inc. sirloin
Richard Greenblat GigaMOS Systems, Inc. sirloin
Jeff Rosenking Grumman Corporation shrimp
Paul Beiser Hewlett Packard Company shrimp
James Kempf Hewlett Packard Company duck
Dave Matthews Hewlett Packard Company lamb
George Hadden Honeywell shrimp
Aaron Larson Honeywell shrimp
Thom Linden IBM shrimp
Mary Van Deusen IBM duck
Greg Nuyens ILOG S.A. duck
Jerome Chailloux INRIA/ILOG duck
Mary Boelk Johnson Controls, Inc. shrimp
Dick Gabriel Lucid, Inc. sirloin
JonL White Lucid, Inc. lamb
Jan Zubkoff Lucid, Inc. duck
Linda DeMichiel Lucid, Inc. lamb
David Loeffler MCC sirloin
Christopher Dabrowski National Bureau of Standards -
Eric Schoen Schlumberger Palo Alto Research -
Chris Perdue Sun Microsystems duck
Sonya Keene Symbolics, Inc. sirloin
Bob Kerns Symbolics, Inc. ??????
David Moon Symbolics, Inc. -
Kent Pitman Symbolics, Inc. duck
Will Clinger Tektronix Laboratories -
David Bartley Texas Instruments lamb
Patrick Dussud Texas Instruments -
Ellen Waldrum Texas Instruments shrimp
Guy Steele Thinking Machines Corporation shrimp
Thomas Turba Unisys Corp. shrimp
Julian Padget University of Bath duck
Jeff Dalton University of Edinburgh sirloin
Daniel Bobrow Xerox Corporation lamb
Pavel Curtis Xerox Corporation lamb
Andy Daniels Xerox Corporation lamb
Gregor Kiczales Xerox Corporation duck
Larry Masinter Xerox Corporation shrimp
∂12-Nov-87 2254 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Parsing 2-dimensional structures
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Nov 87 22:52:13 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Thu 12 Nov 87 08:50:11-PST
Received: by lindy.stanford.edu; Thu, 12 Nov 87 08:44:02 PST
Received: by Forsythe.Stanford.EDU; Thu, 12 Nov 87 08:42:35 PST
Received: by NDSUVM1 (Mailer X1.24) id 9788; Thu, 12 Nov 87 10:16:03 CST
Date: 12 Nov 1987 11:07:38-EST (Thursday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Charlie Martin <CRM%CS.DUKE.EDU@forsythe.stanford.edu>
Subject: Parsing 2-dimensional structures
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
I would appreciate any pointers to theoretical (or for that matter,
practical) papers on parsing arbitrary line-drawings.
Thanks in advance,
Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)
∂12-Nov-87 1317 emma@russell.stanford.edu CSLI Calendar, November 12, 3:7
Received: from RUSSELL.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Nov 87 13:17:01 PST
Received: from localhost by russell.stanford.edu (3.2/4.7); Thu, 12 Nov 87 10:57:09 PST
Date: Thu, 12 Nov 87 10:56:58 PST
From: emma@russell.stanford.edu
Subject: CSLI Calendar, November 12, 3:7
------- Blind-Carbon-Copy
To: friends
Subject: CSLI Calendar, November 12, 3:7
Date: Thu, 12 Nov 87 10:56:58 PST
From: emma
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
12 November 1987 Stanford Vol. 3, No. 7
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR NEXT THURSDAY, 19 November 1987
12 noon TINLunch
Ventura Hall No TINLunch
Conference Room
2:15 p.m. CSLI Seminar
Room G-19 Anaphora and Linking Theory
Redwood Hall Paul Kiparsky (kiparsky@csli.stanford.edu)
Abstract in next week's calendar
3:30 p.m. Tea
Ventura Hall
--------------
------- End of Blind-Carbon-Copy
∂12-Nov-87 1335 X3J13-mailer next meeting
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 12 Nov 87 13:34:57 PST
Date: 12 Nov 1987 16:18-EST
Sender: MATHIS@A.ISI.EDU
Subject: next meeting
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]12-Nov-87 16:18:49.MATHIS>
I've talked to Dave Matthews. If there are any other remaining
reservations, please let him know.
The agenda will be committee reports and regular business on
Tuesday morning. Tuesday afternoon I think will be best spent on
more informal, but more in depth, discussions of the work of the
CLOS and clean-up committees. Wednesday will contain a
continuation of these discussions and also the formulation of a
ballot on clean-up issues (since they haven't been distributed in
advance we can't finalize the vote at the meeting, on the other
hand we may not be to the stage of having a formal mail ballot
either).
We also have to discuss our plans for a standard for Common Lisp
and our plans for the ISO work. There will also be reports from
the editorial, windows, characters, and other subcommittees.
The agenda is not full of a lot of little topics, but is oriented
toward reaching some general understanding of the issues
involved.
-- Bob
∂12-Nov-87 1400 @Score.Stanford.EDU:CLAPP@Sushi.Stanford.EDU lunch for women interested in CS
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Nov 87 14:00:29 PST
Received: from Sushi.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 12 Nov 87 13:54:18-PST
Date: Thu 12 Nov 87 13:53:55-PST
From: I'd really rather be playing frisbee <CLAPP@Sushi.Stanford.EDU>
Subject: lunch for women interested in CS
To: faculty@Sushi.Stanford.EDU
cc: clapp@Sushi.Stanford.EDU
Message-ID: <12350105174.20.CLAPP@Sushi.Stanford.EDU>
We are planning a lunch for undergraduate women interested in Computer
Science. Several faculty members attended a similar lunch we had last
spring, and we received a very positive response from the women about
the opportunity to talk with faculty members. Thus, we would like to
see some faculty members at this lunch as well.
The lunch is scheduled for November 23 at the Faculty Club. If you
are interested in attending, please send mail to CLAPP@sushi by
November 20.
Thanks,
Nancy Clapp
-------
∂12-Nov-87 1455 @Score.Stanford.EDU,@Sushi.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: lunch for women interested in CS
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Nov 87 14:55:12 PST
Received: from Sushi.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 12 Nov 87 14:48:29-PST
Received: from SAIL.Stanford.EDU by Sushi.Stanford.EDU with TCP; Thu 12 Nov 87 14:41:55-PST
Date: 12 Nov 87 1446 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: lunch for women interested in CS
To: CLAPP@SUSHI.STANFORD.EDU
CC: faculty@SUSHI.STANFORD.EDU
Nov 23 lunch is the meeting for the PhD adm (administration and admissions)
committee. If you can reschedule it (but not for a Tuesday), some people
including myself might be able to make it than the current date.
Arthur
∂12-Nov-87 1548 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: Parsing 2-dimensional structures
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Nov 87 15:48:47 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Thu 12 Nov 87 15:39:01-PST
Received: by lindy.stanford.edu; Thu, 12 Nov 87 15:38:01 PST
Received: by Forsythe.Stanford.EDU; Thu, 12 Nov 87 15:26:15 PST
Received: by NDSUVM1 (Mailer X1.24) id 8077; Thu, 12 Nov 87 16:53:51 CST
Date: 12 Nov 1987 17:45:38-EST (Thursday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: VISTNES@coyote.stanford.edu
Subject: Re: Parsing 2-dimensional structures
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
What exactly do you mean by 'parsing' line drawings? I'm not in
theory, but in computer vision. There has been some work in
interpreting line drawings of 3D objects with the goal of trying to
reconstruct 3D info from the 2D drawing. A colleague has done some
work in this area, which is mainly theoretical. He's Vic Nalwa, now
at Bell Labs; his thesis is "Edge detection and Line drawing
interpretation" from Stanford. If this is of interest, you could
get in touch with him (I can give you his address or more info
if you want).
∂12-Nov-87 1700 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Seminar in Applications of Logic to Computer Science
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Nov 87 16:59:54 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Thu 12 Nov 87 16:50:20-PST
Received: by lindy.stanford.edu; Thu, 12 Nov 87 16:11:24 PST
Received: by Forsythe.Stanford.EDU; Thu, 12 Nov 87 16:04:44 PST
Received: by NDSUVM1 (Mailer X1.24) id 8862; Thu, 12 Nov 87 16:58:29 CST
Date: 12 Nov 1987 17:45:44-EST (Thursday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Rohit Parkih <RIPBC%CUNYVM.BITNET@forsythe.stanford.edu>
Subject: Seminar in Applications of Logic to Computer Science
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
SEMINAR IN APPLICATIONS OF LOGIC TO COMPUTER SCIENCE
This seminar meets at the City University Graduate Center, 33 W
42nd Street, New York, room 1223, Tuesdays from 11-12:30 (app). The next
meetings will be:
November 17, Jan Plaza, More on Extensions of Kripke's Theory of Truth
November 24, Dana Latch, Automated Induction Proofs in Functional
Programming: A Boyer-Moore Approach
∂13-Nov-87 0809 MAZZETTI@SUMEX-AIM.STANFORD.EDU [Bob Engelmore <Engelmore@SUMEX-AIM.STANFORD.EDU>: Re: Letter]
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 Nov 87 08:09:24 PST
Date: Fri, 13 Nov 87 08:07:55 PST
From: Claudia Mazzetti <MAZZETTI@SUMEX-AIM.STANFORD.EDU>
Subject: [Bob Engelmore <Engelmore@SUMEX-AIM.STANFORD.EDU>: Re: Letter]
To: officers: ;
Message-ID: <12350304333.27.MAZZETTI@SUMEX-AIM.STANFORD.EDU>
Below is a msg from Bob Engelmore for your review.
-Claudia
---------------
Mail-From: ENGELMORE created at 3-Nov-87 11:30:54
Date: Tue, 3 Nov 87 11:30:54 PST
From: Bob Engelmore <Engelmore@SUMEX-AIM.STANFORD.EDU>
Subject: Re: Letter
To: AAAI-OFFICE@SUMEX-AIM.STANFORD.EDU
cc: MAZZETTI@SUMEX-AIM.STANFORD.EDU
In-Reply-To: <12347707508.71.AAAI-OFFICE@SUMEX-AIM.STANFORD.EDU>
Office-Phone: (415) 723-8444
Message-ID: <12347719844.32.ENGELMORE@SUMEX-AIM.STANFORD.EDU>
Claudia,
Here's the response I intend to publish at the end of the three letters
criticizing my selection of the Letovsky article:
"Letovsky's piece was intended to be an entertainment, not a serious conference
report. I enjoyed reading it, for its discussion (clearly biased) of the
monist-dualist controversy, and for its youthful enthusiasm. It is not
representative of a "mainstream" article in the AI Magazine, nor will it ever
be as long as I'm the editor. Once in a while, however, I will accept
something that's controversial and/or humorous and perhaps even outrageous.
And, once in while, I will make mistakes.
Bob Engelmore"
-------
-------
∂13-Nov-87 0836 MAZZETTI@SUMEX-AIM.STANFORD.EDU [Bob Engelmore <Engelmore@SUMEX-AIM.STANFORD.EDU>: please circulate to AAAI Council and Officers]
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 Nov 87 08:36:49 PST
Date: Fri, 13 Nov 87 08:33:17 PST
From: Claudia Mazzetti <MAZZETTI@SUMEX-AIM.STANFORD.EDU>
Subject: [Bob Engelmore <Engelmore@SUMEX-AIM.STANFORD.EDU>: please circulate to AAAI Council and Officers]
To: officers: ;
Message-ID: <12350308950.36.MAZZETTI@SUMEX-AIM.STANFORD.EDU>
Boy, did I blow it! I send you the wrong msg from Bob Engelmore.
As you can see from both msgs, the life of editor-in-chief can
be difficult.
-Claudia
---------------
Mail-From: ENGELMORE created at 9-Nov-87 10:54:00
Date: Thu, 5 Nov 87 11:22:18 PST
From: Bob Engelmore <Engelmore@SUMEX-AIM.STANFORD.EDU>
Subject: please circulate to AAAI Council and Officers
To: aaai-office@SUMEX-AIM.STANFORD.EDU
cc: rogers@SUMEX-AIM.STANFORD.EDU
Office-Phone: (415) 723-8444
Message-ID: <12348242565.55.ENGELMORE@SUMEX-AIM.STANFORD.EDU>
ReSent-Date: Mon, 9 Nov 87 10:54:00 PST
ReSent-From: Bob Engelmore <Engelmore@SUMEX-AIM.STANFORD.EDU>
ReSent-To: mazzetti@SUMEX-AIM.STANFORD.EDU
ReSent-Message-ID: <12349285989.52.ENGELMORE@SUMEX-AIM.STANFORD.EDU>
Dear Council Members and Officers:
I would like to correct a problem we are having with the AI Magazine, and
I seek your help.
It's pretty common knowledge that our Book Review section ranges from skimpy
to non-existent. Our present book review editor has not been productive, and
I think it's time to find someone else to fill that position. I haven't been
able to identify a replacement thus far, so I am asking all of you, with your
wide network of contacts, to suggest some suitable people.
I'm looking for someone who loves literature, has good taste, a proper sense
of perspective about our field, has the time and inclination to contact people
all over the country and solicit reviews, is well enough organized to follow
up on the reviewers and gently but persuasively encourage them to finish their
reviews, is occasionally willing to write a review himself or herself, and
perhaps is looking for more exposure in the AI community. If you know of
someone who has all or most of these qualifications, please let me know.
Thanks,
Bob Engelmore
-------
-------
∂13-Nov-87 0908 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: Parsing 2-dimensional structures
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 Nov 87 09:08:04 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Fri 13 Nov 87 08:50:49-PST
Received: by lindy.stanford.edu; Fri, 13 Nov 87 07:53:40 PST
Received: by Forsythe.Stanford.EDU; Fri, 13 Nov 87 07:54:12 PST
Received: by NDSUVM1 (Mailer X1.24) id 0680; Fri, 13 Nov 87 09:27:48 CST
Date: 13 Nov 1987 10:21:15-EST (Friday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Dr. Dennis R. Bahler" <DRB%CSCADM.NCSU.EDU@forsythe.stanford.edu>
Subject: Re: Parsing 2-dimensional structures
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
In article <10601@duke.cs.duke.edu>, crm@duke.cs.duke.edu (Charlie Martin) write
> I would appreciate any pointers to theoretical (or for that matter,
> practical) papers on parsing arbitrary line-drawings.
>
> Thanks in advance,
>
> --
> Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)
Much of this sort of work has appeared in the Workshops on Graph Grammars
(there have been 3 so far), in particular
R. Siromoney, "Advances in Array Languages"
H. Gottler, "Graph Grammars and Diagram Editing"
These are both from '86.
See also
%A G. Biswas
%A R. C. Dubes
%T Some experiments in two-dimensional grammatical inference
%J Info. Proc. Letters
%V 2
%D 1984
%P 173-177
%A John Pfaltz
%A Azriel Rosenfeld
%T Web Grammars
%J IJCAI69
%P 609-619
%A John Pfaltz
%T Graph Structures
%J JACM
%V 19
%N 3
%D JUL 1972
%P 411-422
%A Gary B. Goates
%A Martin L. Griss
%A Gary J. Herron
%T Picturebalm: A Lisp-Based Graphics Language System with Flexible
Syntax and Hierarchical Data Structure
%J Computer Graphics
%V 14
%N 3
%D JUL 1980
%P 93-99
%A William R. Mallgren
%T Formal Specification of Interactive Graphics Programming Languages
%I DCS, UNIV of Washington (Ph. D. DISS)
%R 81-09-01
%C Seattle
%D SEP 1981
Hope this helps.
-----------------------------------
Dennis Bahler
Dept. of Computer Science INTERNET - drb@cscadm.ncsu.edu
North Carolina State University CSNET - drb%cscadm.ncsu.edu@relay.cs.net
Raleigh, NC 27695-8206 UUCP - ...!decvax!mcnc!ncsu!cscadm!drb
∂13-Nov-87 1203 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: undecidability of system of first order predicates
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 Nov 87 12:03:05 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Fri 13 Nov 87 11:54:06-PST
Received: by lindy.stanford.edu; Fri, 13 Nov 87 11:56:58 PST
Received: by Forsythe.Stanford.EDU; Fri, 13 Nov 87 11:57:34 PST
Received: by NDSUVM1 (Mailer X1.24) id 7890; Fri, 13 Nov 87 13:29:57 CST
Date: 13 Nov 1987 14:21:40-EST (Friday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "John B. Nagle" <JBN@glacier.stanford.edu>
Subject: Re: undecidability of system of first order predicates
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
Undecidability is a consequence of allowing infinity into a
system. Finite, deterministic systems should be decidable.
More specificially, any finite sequential machine with deterministic
state transitions is immune to the halting problem. (Such a machine
must within a finite time either halt or repeat a previous state.
In the latter case it is in a loop. Yes, this may take a long time.
But a long time is not an infinite one.)
Look into Boyer-Moore theory (A Computational Logic, Academic
Press, 1970). You might find it interesting; although not quite
what you are looking for, a restricted version of Boyer-Moore theory
might provide a way to address your problem. Boyer-Moore theory does
allow infinity, but in a way controlled enough that it might be possible
to eliminate it.
∂14-Nov-87 0353 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #86
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 14 Nov 87 03:53:20 PST
Date: Fri 13 Nov 1987 10:55-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #86
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Saturday, 14 Nov 1987 Volume 5 : Issue 86
Today's Topics:
Announcement - Final CADE9 Call,
Implementation - Types,
LP Library - List Package & Type Checker
----------------------------------------------------------------------
Date: Wed, 4 Nov 87 12:45:07 cst
From: stevens@anl-mcs.ARPA (Rick L. Stevens)
Subject: Final CADE-9 Call for Papers
Final Call for Papers
9th International Conference on Automated
Deduction
May 23-26, 1988
CADE-9 will be held at Argonne National Laboratory (near
Chicago) in celebration of the 25th anniversary of the
discovery of the resolution principle at Argonne in the sum-
mer of 1963. Papers are invited in the following or related
fields:
Theorem Proving Logic Programming
Unification Deductive Databases
Term Rewriting ATP for Non-Standard Logics
Program Verification Inference Systems
Papers are solicited in three categories:
Long papers: 20 pages, about 5000 words
Short papers: 10 pages, about 2500 words
Extended Abstracts of Working Systems: 2 pages
Problem sets: 5 pages
Long papers are expected to present substantial research
results. Short papers are a forum for briefer presentations
of the results of ongoing research. Extended abstracts are
descriptions of existing automated reasoning systems and
their areas of application. Problem sets should present a
complete, formal representation of some collection of
interesting problems for automated systems to attack. The
problems should currently unavailable in the existing
literature. Three copies should be sent to arrive before
November 23rd, 1987 to
Ewing Lusk and Ross Overbeek, chairmen
CADE-9
Mathematics and Computer Science Division
Argonne National Laboratory
9700 South Cass Avenue
Argonne, IL 60439
Schedule:
November 23, 1987: papers due
January 25, 1988: notification of authors
February 21, 1988: final manuscripts due
Questions should be directed to E. L. Lusk (lusk@anl-
mcs.arpa, phone 312-972-7852) or Ross Overbeek
(overbeek@anl-mcs.arpa, phone 312-972-7856)
------------------------------
Date: 31 Oct 87 16:19:00 GMT
From: reddy@b.cs.uiuc.edu
Subject: Types Utilizations in Prolog
I don't know if Lee's message got cut off in the middle somewhere on
the net. But, I didn't see an important reference mentioned in his
list.
Mycroft and O'Keefe, A polymorphic type system for Prolog,
Artificial Intelligence, 23:295-307 (1984).
An implementation of this system exists. But, it needs lots of
declarations. You can probably ask O'Keefe for a copy of the system.
For an early reference on the theory of type "inference", see
Mishra, Towards a theory of types in Prolog, IEEE Intl. Symp
on Logic Programming, 1984, 289-298.
------------------------------
Date: 3 Nov 87 03:02:00 GMT
From: munnari!mulga!philip@uunet.uu.net (Philip Dart)
Subject: Doubly-linked list package
% Following the comments about Fortran as an AI language,
% Melbourne University Department of Artificial Intelligence
% has decided to convert all of its Fortran AI programs to NU-Prolog.
% This package has been written as an aid to this conversion.
% For non-NU-Prolog users, simply comment out the when declarations.
% Doubly-linked list package.
% Why use boring old single-linked lists when doubly-linked
% list could make your list processing applications
% run as never before.
% ?- dAdj(L, R) when L and R. % Are these adjacent nodes?
% ?- dPrev(D, _) when D. % Get previous node.
% ?- dNext(D, _) when D. % Get next node.
% ?- dHead(D, _) when D. % Get head of list
% ?- dTail(D, _) when D. % Get tail of list
% ?- isD(D) when D. % Is this a doubly-linked list?
% ?- portray(D) when ever. % Portray doubly-linked list
% ?- dAppend(X, Y, Z) when X or Z. % Append for doubly-linked lists
test :-
L1 = [1, 2, 3],
listToD(L1, D1),
write(L1), write(' <=> '), portray(D1), nl,
L2 = [4, 5, 6, 7],
listToD(L2, D2),
write(L2), write(' <=> '), portray(D2), nl,
dAppend(D1, D2, D3),
listToD(L3, D3),
isD(D3),
write(L3), write(' <=> '), portray(D3), nl.
?- dAdj(L, R) when L and R. % Are these adjacent nodes?
dAdj(L, R) :-
L = d(_, _, R),
R = d(L, _, _).
?- dPrev(D, _) when D. % Get previous node.
dPrev(d(L, _, _), L).
?- dNext(D, _) when D. % Get next node.
dNext(d(_, _, R), R).
?- dHead(D, _) when D. % Get head of list
dHead([], []).
dHead(d([], D, R), d([], D, R)).
dHead(d(d(L, D, R), _, _), H) :-
dHead(d(L, D, R), H).
?- dTail(D, _) when D. % Get tail of list
dTail([], []).
dTail(d(L, D, []), d(L, D, [])).
dTail(d(_, _, d(L, D, R)), T) :-
dTail(d(L, D, R), T).
?- listToD(List, D) when List or D. % Convert single to doubly-linked list
listToD([], []).
listToD(H.T, D) :-
D = d([], H, R),
$listToD(T, D, R).
?- $listToD(List, _, D) when List or D.
$listToD([], _, []).
$listToD(H.T, L, D) :-
D = d(L, H, R),
$listToD(T, D, R).
?- isD(D) when D. % Is this a doubly-linked list?
isD([]).
isD(D) :-
D = d([], _, R),
$isD(D, R).
?- $isD(_, D) when D.
$isD(_, []).
$isD(L, D) :-
D = d(L, V, R),
$isD(D, R).
?- portray(D) when ever. % Portray doubly-linked list
portray(D) :-
nonvar(D),
D = d([], _, _),
display('[]:'),
$dPrint(D).
?- $dPrint(D) when D.
$dPrint([]) :-
display('[]').
$dPrint(d(_, V, R)) :-
display(V),
display(':'),
$dPrint(R).
?- dAppend(X, Y, Z) when X or Z. % Append for doubly-linked lists
dAppend(X, [], X).
dAppend([], d([], D, R), d([], D, R)).
dAppend(d(L, X, R), d([], Y, RY), Z) :-
$dAppend([], d(L, X, R), Y, RY, Z).
?- $dAppend(X, _, _, Z) when X or Z.
$dAppend(L, d(_, X, []), Y, R, Z) :-
Z = d(L, X, H),
H = d(Z, Y, R1),
$dAppend1(H, R, R1).
$dAppend(L, d(_, X, d(L1, X1, R1)), Y, RY, d(L, X, RZ)) :-
Z = d(L, X, RZ),
$dAppend(Z, d(L1, X1, R1), Y, RY, RZ).
?- $dAppend(_, Y, Z) when Y or Z.
$dAppend1(_, [], []).
$dAppend1(L, d(_, D, R), Z) :-
Z = d(L, D, R1),
$dAppend1(Z, R, R1).
% P.S. Don't forget to turn off the occur-check in your version of Prolog!
------------------------------
Date: Sun, 8 Nov 87 17:35:58 PST
From: quintus!ok@Sun.COM (Richard A. O'Keefe)
Subject: Type checker
Disclaimer:
the timestamps on the following two files are
correct. This is the type-checker as it stood
in 1984 for DEC-10 Prolog + Edinburgh library
(pretty much the code that was handed out at the
Albufeira Workshop in '83, in fact). It has not
been upgraded to Quintus Prolog; it doesn't
handle modules, and it was never considered to
be particularly good code. Comments and
improvements welcome.
------------------------------------------------------------------------
% File : TYPECH.PL
% Author : Alan Mycroft & R.A.O'Keefe
% Updated: 8 June 1984
% Purpose: Prolog type-checker
:- public
load/1, % for users
type_check/5. % for setof/3
%>> This module uses unify/2 from Util:MetUtl.Pl .
%>> It also uses append/3 from the utilities.
% This program defines a "type-checked consult" operation
% load(Files)
% where Files is an atom or a list of atoms. There is no
% analogue of the reconsult operation. In the Files type
% declarations may be given in addition to the usual sort
% of commands, questions, clauses, and declarations. You
% can put the type declarations in separate files, so that
% load(['foo.typ','foo.pl']) can be used to type-check and
% load the interpreted version, and compile('foo.pl') can
% be used to compile the same code. Note that declarations
% have to be processed before clauses using the things
% declared.
% There are two new declarations:
% type <type term> --> <constr>{| <constr>}.. .
% e.g. type tree(T) --> empty | tree(T,tree(T),tree(T)).
% and
% pred <pred decl>{, <pred decl>}.. .
% e.g. pred append(list(T), list(T), list(T)).
% You may use a semicolon instead of a vertical bar if you like.
% As a convenience for defining grammar rules,
% rule p(T1,...,Tk).
% has the same effect as
% pred p(T1,...,Tk,list(T_),list(T_)).
% where T_ is not further specified. 'C'/3 is predefined as
% pred 'C'(list(X), X, list(X)).
:- op(1199, fx, [(type), (pred), (rule)]).
:- op(1198, xfy, (-->)).
:- op( 999, xfy, (:)).
% load/1 is defined in the usual way. The juggling with (no)fileerrors
% is to determine whether failure to find a file causes an error message
% and abort, or just (as here) a failure. expandterm/2 is where grammar
% rules are translated to ordinary Prolog. In Dec-10 Prolog, the style
% of programming which uses failure-driven loops is nearly obsolete,
% thanks to the introduction of TRO to the compiler, and it was never
% considered to be anything other than a hack. However, this stuff has
% to be useful in C Prolog and other Prologs which still lack TRO, so
% the hack remains.
load(Files) :-
recorded(void, (type), _),
!, % the definitions have been loaded
load1(Files).
load(Files) :-
recordz(void, (type), _),
recordz(any, (type), _),
recordz((_:-_), type((void:-void), void), _), % for assert
load1(['util:prolog.typ'|Files]).
load1(Var) :-
var(Var),
!,
write('! load: argument contains a variable'), nl,
fail.
load1([Head|Tail]) :- !,
load1(Head), !, % discard this cut on non-TRO systems
load1(Tail).
load1(File) :-
atom(File),
!,
nofileerrors,
seeing(Old),
load2(File),
fileerrors,
see(Old).
load1(File) :-
write('! load: argument not list or atom: '),
write(File), nl,
fail.
load2(File) :-
see(File),
repeat,
read(Term),
expand_term(Term, Expanded),
process_term(Expanded, File),
Expanded = end_of_file,
!,
seen,
write(File), write(' loaded.'), nl.
load2(File) :-
write('! load: can''t see '),
write(File), nl,
fail.
% process_term(Expansion, File)
% handles a command, question, clause, or declaration.
% Questions are treated as if they were commands, which is just plain
% wrong, but only in Prolog-X is a version of 'read' standardly
% available which gives you a name->variable list so that you can
% print the answers. Type checking wants to be built into a Prolog
% system top level from the word go, not added on as an afterthought.
process_term(end_of_file, File) :- !.
process_term((:- Command), File) :- !,
process_command(Command, File).
process_term((?- Question), File) :- !,
process_command(Question, File).
process_term({Unchecked}, File) :- !,
assertz(Unchecked).
process_term((Head :- Body), File) :- !,
type_check((Head:-Body), Clause),
assertz(Clause).
process_term(Head, File) :-
type_check((Head:-true), Clause),
assertz(Clause).
% process_command(Command, File)
% mainly handles declarations.
process_command((type Type --> Constructors), File) :- !,
process_type(Type, Constructors).
process_command((pred Predicates), File) :- !,
process_pred(Predicates, (pred)).
process_command((rule GrammarRules), File) :- !,
process_pred(GrammarRules, (rule)).
process_command([Files], File) :- !,
load1(Files).
process_command((mode Modes), File) :- !,
true. % could maybe note that we expect a type?
process_command((public PublicDeclarations), File) :- !,
true. % could maybe note that we expect a type?
process_command(Question, user) :- !,
( type_check(Question, Checked)
; write('! ill-typed '), nl, fail
),
( call(Checked),
write(Checked), nl, write('more? '), ttyflush,
read(no)
; write('no (more) answers'), nl
).
process_command(Command, File) :-
( type_check(Command, Checked)
; write('! ill-typed '), write(Command),
write(' in '), write(File), nl, fail
),
( call(Checked), !
; write('! failed command '), write(Command),
write(' in '), write(File), nl, fail
).
% The "typed premise" described in Mycroft & O'Keefe is stored two
% ways. The types of variables are held in a dynamic data structure
% used only within a single clause. The types of predicates and
% functors are held in the data base. We use the Dec-10 "recorded"
% data base here to reduce clashes with user clauses and make access
% a little bit faster, but ordinary clauses could just as easily be
% used. There are three cases:
%
% recorded(Key, (type), _)
% - use type_def(Key) as clauses
% means that the Key is a type constructor. E.g. after
% processing the declaration :- type tree(T) --> ... .
% recorded(tree(T), (type), _)
% would be true.
%
% recorded(Key, type(Pat,void), _)
% - use has_type(Key, Pat, void) as clauses
% means that the Key is defined as a predicate. The Pat looks like
% the Key, but has type terms for its arguments. E.g. after
% processing the declaration :- pred elem(T, tree(T)).
% recorded(elem(_,_), type(elem(T,tree(T)),void), _)
% would be true.
%
% recorded(Key, type(Pat,Val), _)
% - use has_type(Key, Pat, Val) as clauses
% means that the Key is defined as a function. The Pat looks like
% the Key, but has type terms for its arguments. E.g. after
% processing the declaration
% :- type tree(T) --> empty | t(T,tree(T),tree(T)).
% recorded(empty, type(empty,tree(T)), _) and
% recorded(t(_,_,_), type(t(T,tree(T),tree(T)),tree(T)), _)
% would both be true.
%
% These declarations are the only way that data of the given forms
% are recorded.
% process_type(<type head>, <type body>)
% checks that its arguments are well formed, and if they are,
% records the type information about the <type head> and the
% constructors.
process_type(Head, Body) :-
check_type_head(Head),
recordz(Head, (type), _), % recorded here for recursive types
check_type_body(Head, Body, Constructors),
process_type_body(Constructors, Head).
process_type_body([Constructor|Constructors], Head) :-
recordz(Constructor, type(Constructor,Head), _), !,
process_type_body(Constructors, Head).
process_type_body([], _).
check_type_head(Head) :-
var(Head),
!,
write('! Type head is a variable.'), nl,
fail.
check_type_head(Head) :-
recorded(Head, (type), _),
!,
write('! Already a type: '), write(Head), nl,
fail.
check_type_head(Head) :-
functor(Head, _, N),
check_type_head(N, Head),
!,
fail.
check_type_head(_).
check_type_head(N, Head) :-
arg(N, Head, Arg),
nonvar(Arg),
write('! Type head argument '), write(N),
write(' is bad.'), nl.
check_type_head(N, Head) :-
arg(N, Head, N),
M is N-1,
check_type_head(M, Head).
% is_type_expr(Term)
% succeeds when Term is a type expression, that is, when all the
% constructors it is made from are type constructors. If we had
% type macros (:- type Lhs = Rhs) this is where we would expand
% them. That will come later.
is_type_expr(Type) :-
var(Type),
!.
is_type_expr(Type) :-
recorded(Type, (type), _),
!,
functor(Type, _, N),
is_type_expr(N, Type).
is_type_expr(Type) :-
write('! not a type: '),
write(Type), nl,
fail.
is_type_expr(0, Type) :- !.
is_type_expr(N, Type) :-
arg(N, Type, Arg),
is_type_expr(Arg),
M is N-1,
!,
is_type_expr(M, Type).
check_type_body(Head, Body, _) :-
numbervars(Head, 0, M),
numbervars(Body, M, N),
N > M,
!,
write('! Rhs of type def contains variables not in lhs.'), nl,
fail.
check_type_body(Head, Body, Constructors) :-
check_type_body_(Body, Constructors, []).
check_type_body_(( Constr1 ; Constr2 ), CL, CR) :- !,
check_type_body_(Constr1, CL, CM),
check_type_body_(Constr2, CM, CR).
check_type_body_({Constructor}, [Constructor|CR], CR) :-
nonvar(Constructor),
functor(Constructor, _, N),
is_type_expr(N, Constructor),
!.
check_type_body_({Constructor}, _, _) :- !,
write('! Dud constructor : '),
write(Constructor), nl,
fail.
check_type_body_(Constructor, CL, CR) :-
check_type_body_({Constructor}, CL, CR).
% process_pred(Preds, Sort)
% processes pred (Sort=pred) and rule (Sort=rule) declarations.
% Several predicates may be declared in one declaration, and they
% may be separated by any mixture of commas and semicolons. To
% declare comma or semicolon as a predicate, you have to put it
% inside braces { }, e.g. :- pred {void,void}. The same escape
% convention is used to let you define these symbols as constructors
% in type declarations.
process_pred(Var, Sort) :-
var(Var),
!,
write('! variable in '), write(Sort),
write(' declaration.'), nl,
fail.
process_pred((Preds1 , Preds2), Sort) :- !,
process_pred(Preds1, Sort),
process_pred(Preds2, Sort).
process_pred((Preds1 ; Preds2), Sort) :- !,
process_pred(Preds1, Sort),
process_pred(Preds2, Sort).
process_pred({Pred}, (pred)) :-
recorded(Pred, type(_,void), _),
!,
write('! already declared: '), write(Pred), nl,
fail.
process_pred({Pred}, (pred)) :- !,
functor(Pred, _, N),
is_type_expr(N, Pred),
recordz(Pred, type(Pred,void), _).
process_pred({Rule}, (rule)) :- !,
Rule =.. List,
append(List, [list(T),list(T)], Full),
Pred =.. Full,
process_pred({Pred}, (pred)).
process_pred(Other, Sort) :-
process_pred({Other}, Sort).
% To perform type checking we use the Milner algorithm with overloading.
% The idea is that we consider (via backtracking) all the type resolutions
% possible, and accept the typing if exactly one type assignment exists.
% For this (second order) operation we use 'setof'. The typed premise
% is in two parts. The predicate and functor assignments are held in the
% data base, the variable assignments (which only have significance within
% the current clause) in held in Tenv (type environment) variables.
% type tenv --> var | var(variable,type,tenv).
type_check(Given, Pruned) :-
setof(P, To↑type_check(Given, P, var, To, void), PP),
( PP = [Pruned], !
; write('! ambiguous overloaded functor.'), nl, !, fail
).
type_check(:-(Head,Body), _) :-
write('% no type can be assigned to the rule'), nl, !,
pp_explicit(:-(Head,Body), Head).
type_check(Head, _) :-
write('% no type can be assigned to the fact'), nl, !,
pp_explicit(Head, Head).
% type_check(Given, Pruned, TenvIn, TenvOut, Expected)
% checks a Given term which is expected to have type Expected.
% It may extend the type environment, as well as further specifying
% existing variable assignments, and it returns the Given term
% Pruned of ":Type" annotations. The point of the latter is to
% help the type system when it comes across an overloaded term that
% it is otherwise unable to resolve.
type_check(X, X, Ti, Ti, Expected) :-
Expected == any,
!. % X had better not contain :annotations!
type_check(Var, Var, Ti, To, Context) :-
var(Var),
!,
type_check(Var, Ti, To, Context).
type_check((Given:Type), Pruned, Ti, To, Expected) :- !,
unify(Type, Expected),
type_check(Given, Pruned, Ti, To, Expected).
type_check((Head:-Body), (Lhs:-Rhs), Ti, To, void) :- !,
recorded(Head, type(HeadT,void), _),
numbervars(HeadT, 0, _), % crucial
functor(Head, F, N),
functor(Lhs, F, N),
type_check(N, Head, Lhs, Ti, Tm, HeadT),
type_check(Body, Rhs, Tm, To, void).
type_check(Int, Int, Ti, Ti, integer) :-
integer(Int),
!. % special hack for numbers
type_check(Given, Pruned, Ti, To, Expected) :-
recorded(Given, type(GivenT, ResultT), _),
unify(ResultT, Expected),
functor(Given, F, N),
functor(Pruned, F, N),
type_check(N, Given, Pruned, Ti, To, GivenT).
% Type check a variable
type_check(Var, Ti, Ti, Expected) :-
varassoc(Ti, Var, VarT),
!,
unify(VarT, Expected).
type_check(Var, Ti, var(Var,Expected,Ti), Expected).
varassoc(var(V,T,_), Var, T) :-
V == Var, !.
varassoc(var(_,_,R), Var, T) :-
varassoc(R, Var, T).
% Type check the arguments of a term. The Given, Pruned, and Expected
% arguments all have the same principal functor, and N is the number
% of arguments still to be checked.
type_check(0, _, _, Ti, Ti, _) :- !.
type_check(N, Given, Pruned, Ti, To, Expected) :-
arg(N, Given, Agiven),
arg(N, Expected, Aexpected),
type_check(Agiven, Apruned, Ti, Tm, Aexpected),
arg(N, Pruned, Apruned),
M is N-1,
% There *MUSTN'T* be a cut here, as we want type_check/5
% to be able to back-track and try another assignment.
type_check(M, Given, Pruned, Tm, To, Expected).
------------------------------------------------------------------------
% File : PROLOG.TYP
% Author : R.A.O'Keefe
% Updated: 23 June 1983
% Purpose: Type definitions for Prolog & utilities
% the two built in types are
% void -- type of goals, truth values
% any -- matches anything at all
:- type integer --> % integers and expressions
integer + integer
| integer - integer
| integer * integer
| integer //integer % was /, should be div
| integer mod integer
| integer /\ integer % bitwise and
| integer \/ integer % bitwise or
| integer << integer % left shift
| integer >> integer % right shift
| + integer
| - integer
| [integer|any].
:- type list(T) --> [] | [T|list(T)].
:- type dbref --> ''. % this is a sort of abstract data type
:- type op --> xf | yf | yfx | xfx | xfy | fy | fx.
:- type order --> < | = | > . % for compare
:- type pair(X,Y) --> X-Y. % for keysort
:- pred {void,void}, % , = conjunction
{void;void}, % ; = disjunction
{void->void}. % -> = if-then
:- pred abolish(any, integer).
:- pred revive(any, integer).
:- pred incore(void).
:- pred asserta(void, dbref).
:- pred asserta(void).
:- pred assertz(void, dbref).
:- pred assertz(void).
:- pred retract(void).
:- pred clause(void, void, dbref).
:- pred clause(void, void).
:- pred recorda(any, any, dbref).
:- pred recordz(any, any, dbref).
:- pred recorded(any, any, dbref).
:- pred instance(dbref, any).
:- pred erase(dbref).
:- pred true.
:- pred length(list(_), integer).
:- pred name(any, list(integer)).
:- pred op(integer, op, any).
:- pred var(any).
:- pred atom(any).
:- pred !.
:- pred statistics.
:- pred statistics(any, any).
:- pred functor(any, any, integer).
:- pred call(void).
:- pred expand_term(any, any).
:- pred debug.
:- pred debugging.
:- pred display(any).
:- pred get(integer).
:- pred get0(integer).
:- pred leash(any).
:- pred nl.
:- pred nodebug.
:- pred print(any).
:- pred put(integer).
:- pred skip(integer).
:- pred tab(integer).
:- pred trace.
:- pred ttyflush.
:- pred ttyget(integer).
:- pred ttyget0(integer).
:- pred ttynl.
:- pred ttyput(integer).
:- pred ttyskip(integer).
:- pred ttytab(integer).
:- pred write(any).
:- pred writeq(any).
:- pred ancestors(list(void)).
:- pred depth(integer).
:- pred maxdepth(integer).
:- pred subgoal_of(void).
:- pred abort.
:- pred arg(integer, any, any).
:- pred assert(void).
:- pred atomic(any).
:- pred bagof(T, void, list(T)).
:- pred break.
:- pred close(any).
:- pred compare(order, any, any).
:- pred compile(any).
:- pred consult(any).
:- pred current_atom(any).
:- pred current_functor(any,any).
:- pred current_predicate(any,any).
:- pred current_op(integer, op, any).
:- pred fail.
:- pred fileerrors.
:- pred gc.
:- pred gcguide(any).
:- pred halt.
:- pred integer(any).
:- pred keysort(list(pair(X,Y)), list(pair(X,Y))).
:- pred listing.
:- pred listing(any).
:- pred log.
:- pred nofileerrors.
:- pred nogc.
:- pred nolog.
:- pred nonvar(any).
:- pred numbervars(any, integer, integer).
:- pred phrase(any, list(_)).
:- pred prompt(any, any).
:- pred read(any).
:- pred reconsult(any).
:- pred rename(any, any).
:- pred repeat.
:- pred restore(any).
:- pred save(any).
:- pred see(any).
:- pred seeing(any).
:- pred seen.
:- pred setof(T, void, list(T)).
:- pred sort(list(T), list(T)).
:- pred tell(any).
:- pred telling(any).
:- pred told.
:- pred trimcore.
:- pred plsys(any).
:- pred 'LC'.
:- pred 'NOLC'.
:- pred spy void.
:- pred nospy void.
:- pred \+ void.
:- pred T = T.
:- pred integer is integer.
:- pred T == T.
:- pred T \== T.
:- pred any =.. list(any).
:- pred integer < integer.
:- pred integer > integer.
:- pred integer =< integer.
:- pred integer >= integer.
:- pred any @< any.
:- pred any @=< any.
:- pred any @>= any.
:- pred any @> any.
:- pred any↑void.
:- pred integer =\= integer.
:- pred integer =:= integer.
% From here on belong to UTIL.
:- pred &(void, void).
:- pred \=(T, T).
:- pred \\(void, void).
:- pred any(list(void)).
:- pred append(list(T), list(T), list(T)).
:- pred apply(any, list(any)).
:- pred binding(any, void).
:- pred casserta(void).
:- pred cassertz(void).
:- pred cgensym(any, any).
:- pred check_exists(any).
:- pred checkand(any, any).
:- pred checklist(any, list(_)).
:- pred clean.
:- pred close(any, any).
:- pred concat(any, any, any).
:- pred continue.
:- pred convlist(any, list(_), list(_)).
:- pred delete(any).
:- pred diff(T, T).
:- pred disjoint(list(_)).
:- pred edit(any).
:- pred error(any, any, any).
:- pred eval(void).
:- pred eval(integer, integer).
:- pred file_exists(any).
:- pred findall(T, void, list(T)).
:- pred flag(any, T, T).
:- pred for(integer, void).
:- pred forall(void, void).
:- pred gcc(void).
:- pred gensym(any, any).
:- pred intersect(list(T), list(T), list(T)).
:- pred last(T, list(T)).
:- pred listtoset(list(T), list(T)).
:- pred mapand(any, any, any).
:- pred maplist(any, list(_), list(_)).
:- pred member(T, list(T)).
:- pred nextto(T, T, list(T)).
:- pred nmember(T, list(T), integer).
:- pred nobt(void).
:- pred not(void).
:- pred number(any).
:- pred numlist(integer, integer, list(integer)).
:- pred occ(any, any, integer).
:- pred open(any).
:- pred open(any, any).
:- pred pairfrom(list(T), T, T, list(T)).
:- pred perm(list(T), list(T)).
:- pred perm2(T, T, T, T).
:- pred read_in(list(T)).
:- pred redo(any).
:- pred remove_dups(list(T), list(T)).
:- pred rev(list(T), list(T)).
:- pred select(T, list(T), list(T)).
:- pred seteq(list(T), list(T)).
:- pred some(any, list(_)).
:- pred subgoal(any, void).
:- pred subset(list(T), list(T)).
:- pred subst(any, T, T).
:- pred subtract(list(T), list(T), list(T)).
:- pred sumlist(list(integer), integer).
:- pred thnot(void).
:- pred tidy(any, any).
:- pred tlim(integer).
:- pred ton(any).
:- pred toff.
:- pred toff(any).
:- pred trace(any, integer).
:- pred trace(any, any, integer).
:- pred union(list(T), list(T), list(T)).
:- pred variables(any, list(T)).
:- pred writef(any).
:- pred writef(any, any).
------------------------------
End of PROLOG Digest
********************
∂15-Nov-87 1331 TAJNAI@Score.Stanford.EDU AT&T Bell Nominations
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 15 Nov 87 13:31:20 PST
Date: Sun 15 Nov 87 13:25:01-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: AT&T Bell Nominations
To: faculty@Score.Stanford.EDU
cc: hayes-Roth@SUMEX-AIM.Stanford.EDU
Message-ID: <12350886346.13.TAJNAI@Score.Stanford.EDU>
Last day to nominate: Friday, Nov. 20.
Students nominated so far are:
Craig Chambers
David Salesin
Sheralyn Listgarten
Michael Wolverton
Alexander Wang
David Mellinger
Please do not discuss this with the students. Only 3 can be nominated.
Chambers and Listgarten are the only ones who have been mentioned by
two faculty members. If you would like to add your "second" to one of
these candidates, please send me a message.
Carolyn
-------
∂16-Nov-87 0759 RICHARDSON@Score.Stanford.EDU Faculty Lunch
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Nov 87 07:59:29 PST
Date: Mon 16 Nov 87 07:52:58-PST
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: Faculty Lunch
To: faculty@Score.Stanford.EDU
cc: wheaton@Bobby-Vinton.Stanford.EDU
Message-ID: <12351088041.17.RICHARDSON@Score.Stanford.EDU>
There will be general discussion (or a topic of your choosing) at the
CSD Faculty lunch on Tuesday, November 17 in MJH 146 at 12:15. (FYI, Nils
is out of town.)
-Anne
-------
∂16-Nov-87 1144 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: undecidability of system of first order predicates
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Nov 87 11:43:55 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Mon 16 Nov 87 11:29:56-PST
Received: by lindy.stanford.edu; Mon, 16 Nov 87 11:32:33 PST
Received: by Forsythe.Stanford.EDU; Mon, 16 Nov 87 11:33:07 PST
Received: by NDSUVM1 (Mailer X1.24) id 6949; Mon, 16 Nov 87 13:11:46 CST
Date: 16 Nov 1987 10:17:41-EST (Monday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Michael Evangelist <WME@mcc.com>
Subject: Re: undecidability of system of first order predicates
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
You should look at "The Decision Problem: Solvable Classes
of Quantificational Formulas," by Burton Dreben and Warren D.
Goldfarb, published in 1979 by Addison-Wesley.
∂16-Nov-87 1204 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: undecidability of system of first order predicates
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Nov 87 12:04:49 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Mon 16 Nov 87 11:39:19-PST
Received: by lindy.stanford.edu; Mon, 16 Nov 87 11:42:05 PST
Received: by Forsythe.Stanford.EDU; Mon, 16 Nov 87 11:42:43 PST
Received: by NDSUVM1 (Mailer X1.24) id 7066; Mon, 16 Nov 87 13:12:26 CST
Date: 16 Nov 1987 10:17:26-EST (Monday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Robert M. Solovay" <CARTAN!FRITO!SOLOVAY%UCBVAX.BERKELEY.EDU@forsythe.stanford.edu>
Subject: Re: undecidability of system of first order predicates
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
In article <8711131158.AA22333@jade.berkeley.edu> TheoryNet List
<THEORYNT%NDSUVM1.bitnet@jade.berkeley.edu> writes:
>Hello,
> I will be glad to receive any information on works either ongoing
>or completed on restrictions that are placed on the forms of predicates
>so that the checking of consistency of such systems becomes decidable.
> Please write to me if you know of any interesting results and proofs.
>Deepest appreciation !
>Best regards,
> Lim Eng-Lian
Dreben and Goldfarb have a book entitled "Solvable Cases of the
Decision Problem" that may be relevant. I believe that Addison-Wesley
is the publisher.
Sincerely,
Bob Solovay
As ever,
Bob Solovay
∂16-Nov-87 1218 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talks
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Nov 87 12:18:48 PST
Date: Mon 16 Nov 87 11:58:50-PST
From: Anil R. Gangolli <GANGOLLI@Sushi.Stanford.EDU>
Subject: Upcoming AFLB Talks
To: aflb.all@Sushi.Stanford.EDU
Office Phone: (415) 723-3605
Message-ID: <12351132802.60.GANGOLLI@Sushi.Stanford.EDU>
PLEASE NOTE THE FOLLOWING:
* This week we have TWO talks. One on Tuesday, Nov. 17 and one
on Thursday, Nov 19.
* Next week, Thursday is Thanksgiving Day. There is no AFLB talk.
THIS WEEK'S TALKS:
17-November-87: Larry J. Stockmeyer (IBM Almaden)
Interactive Proof Systems
With Finite State Verifiers
An Interactive Proof System (IPS) for membership in a language L is a
two-party protocol whereby a ``prover'' can convince a ``verifier''
that elements x are in L. Both the prover and the verifier may make
random moves (flip coins).
To date, almost all research in interactive proof systems has dealt
with the case that the verifier is a probabilistic Turing machine
(ptm) which runs in polynomial time. Several classes of interactive
proof systems have been defined, for example, (1) the verifier may
employ either public coins or private coins, defined according to
whether the prover can see the outcomes of the random choices made by
the verifier; (2) the IPS may or may not be zero-knowledge, meaning,
roughly speaking, that no verifier can extract any information from
the interactive proof that x is in L except for the fact that x is in
L. Many previous results for ptm verifiers depend on unproved
assumptions.
By restricting attention to verifiers which are 2-way probabilistic
finite state automata (2pfa's), we obtain results about IPS's without
unproved assumptions. This talk will focus on three results: (1)
private coins are more powerful than public coins; (2) IPS's with
public coins are more powerful than 2pfa's alone; (3) there is a
language with an IPS but with no zero knowledge IPS.
(This is joint work with Cynthia Dwork who will speak at the Nov. 12
BATS on this work. Different material will be emphasized in the two
talks.)
***** Time and place: Tue, November 17, 12:30pm in MJH 352 (Bldg. 460)
********* NOTE UNUSUAL DAY **********
19-November-87: Valerie King (Berkeley)
"Lower Bounds on the Complexity of Graph Properties"
In this simple model, a decision tree algorithm must determine whether an
unknown graph on nodes {1,2,...,n} has a given property by asking questions
of the form "Is edge {i,j} in the graph?". The complexity of a property is
the number of questions which must be asked in the worst case. A property is
called evasive if its complexity is equal to the number of edges in the
complete graph.
In 1973, Aanderaa and Rosenberg conjectured that any property which is a
graph or digraph property (invariant under graph isomorphism) and is monotone
(not destroyed by the deletion of edges) and nontrivial (holds for some but
not all graphs) has complexity at least c n↑2 where n is the number of nodes
and c is a constant. This conjecture was proved by Rivest and Vuillemin who
found a constant of 1/16.
In 1984, Kahn, Saks, and Sturtevant discovered that algebraic topology could be used to prove evasiveness when n is a prime power. A consequence of this was
a lower bound of almost 1/4 n↑2 for graph and digraph properties and general
n. Recently, their technique was used to prove evasiveness for all monotone,
nontrivial bipartite graph properties (Yao, 1987) and a further improvement on
the Aanderaa-Rosenberg constant, to almost 1/2 n↑2 for all monotone nontrivial
digraph properties (King, 1987).
This talk will describe the method developed by KSS and its new applications.
***** Time and place: Thu, November 19, 12:30pm in MJH 352 (Bldg. 460)
-------
∂16-Nov-87 1546 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu the synthesis of communication protocols
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Nov 87 15:46:26 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Mon 16 Nov 87 15:35:58-PST
Received: by lindy.stanford.edu; Mon, 16 Nov 87 15:38:42 PST
Received: by Forsythe.Stanford.EDU; Mon, 16 Nov 87 15:39:20 PST
Received: by NDSUVM1 (Mailer X1.24) id 2349; Mon, 16 Nov 87 16:51:02 CST
Date: 16 Nov 1987 10:17:32-EST (Monday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Oliver <MUNNARI!MIMIR!WACSVAX!RACHEL@uunet.uu.net>
Subject: the synthesis of communication protocols
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
I am looking for any information about an idea presented by
Foto Afrati, Christos Papadimitriou and George Papageorgiou on "The
Synthesis of Communication Protocols" at the 5th ACM Symposium on the
Principles of Distributed Computing, 1986.
The paper presents a model for the synthesis of communication protocols
from a specification using a directed graph of entities, some of which
are unreliable, connected by directed communication channels. Knowledge
assertions are used to give the initial and final states of the network.
The result of the synthesis algorithm is a set of communicating finite
automata, one for each entity. Is there a full paper which describes the
synthesis algorithm ? Are there other researchers working on this
problem ?
Please reply by mail. I will summarize replies if there is sufficient
interest.
Many thanks,
Rachel Cardell-Oliver rachel@wacsvax.oz
Department of Computer Science
The University of Western Australia
NEDLANDS 6009
∂16-Nov-87 1606 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Sanitary surgeons and safe sex.
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Nov 87 16:06:24 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Mon 16 Nov 87 15:55:28-PST
Received: by lindy.stanford.edu; Mon, 16 Nov 87 15:58:11 PST
Received: by Forsythe.Stanford.EDU; Mon, 16 Nov 87 15:58:53 PST
Received: by NDSUVM1 (Mailer X1.24) id 2850; Mon, 16 Nov 87 17:14:24 CST
Date: 16 Nov 1987 10:17:55-EST (Monday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Gregory J. E. Rawlins" <IUVAX!RAWLINS%RUTGERS.EDU@forsythe.stanford.edu>
Subject: Sanitary surgeons and safe sex.
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
In article <18874@yale-celray.yale.UUCP> shefter@yale-zoo-suned.UUCP
(Bret A. Shefter) writes:
>Three doctors are going to operate on a seriously ill patient. Dr. Stevens
>points out that each of the three doctors will need to operate, one after the
>other, in his or her special area to save the patient's life, and there can be
>no pauses. Dr. Rimaldi mentions that, as there is a strange disease going about
>that can be spread by touch, and none of them knows whether his or her fellow
>doctors has it (or even if the patient does), since the symptoms do not mani-
>fest for three weeks, they had all better use different gloves, even though
>they will not be operating together. Dr. Watson (sorry!) discovers that, alas,
>there are only two clean pairs of rubber gloves. What to do, what to do?
[To rec.puzzle readers: this posting is not a spoiler for this puzzle.]
This is the sanitary surgeons puzzle first proposed, to the best of my
knowledge, in Martin Gardner's _Aha! Insight_ (Freeman, 1978). I first
saw (a generalization of) this puzzle in a graduate class in complexity
theory at Waterloo several years ago. The generalization -- first
proposed (again, to the best of my knowledge) at either STOC or FOCS
circa 1979 -- has since gained notoriety in the complexity theory
underground. The reason being that it was posed as the following safe
sex puzzle:
Given n heterosexual couples, each person wants to have sex with every
person of the opposite sex. However, everyone is afraid of transmitting
or receiving a communicable disease. They decide that condoms give best
protection. What is the minimum number of condoms necessary?
Hint: show that for n=2, two condoms are necessary and sufficient.
Have fun!
gregory.
P.S. The solution is know (but not published anywhere!). I would be
interested in hearing from anyone who has more detail on either the
history of this problem or its further generalization to n males and m
females. This problem is more usually stated as a problem in optimization
research.
--
Gregory J. E. Rawlins; Dept CS, Indiana University, rawlins@iuvax.cs.indiana.edu
∂16-Nov-87 1646 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu CMU meeting on metadeduction
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Nov 87 16:46:47 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Mon 16 Nov 87 16:08:58-PST
Received: by lindy.stanford.edu; Mon, 16 Nov 87 16:11:40 PST
Received: by Forsythe.Stanford.EDU; Mon, 16 Nov 87 16:12:02 PST
Received: by NDSUVM1 (Mailer X1.24) id 3028; Mon, 16 Nov 87 17:18:59 CST
Date: 16 Nov 1987 10:17:49-EST (Monday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: DANIEL.LEIVANT%THEORY.CS.CMU.EDU@forsythe.stanford.edu
Subject: CMU meeting on metadeduction
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
Below is the schedule of a meeting that has taken place at
Carnegie Mellon University, on
METALANGUAGE AND TOOLS FOR MECHANIZING FORMAL DEDUCTIVE THEORIES
Please address requests for abstracts of talks
to jfm@k.gp.cs.cmu.edu (ARPAnet).
Friday, November 13
9:00 Using a Higher-Order Logic Programming Language to Implement
Program Transformations
Dale Miller, University of Pennsylvania
9:45 Building Proof Systems in an Extended Logic Programming Language
Amy Felty, University of Pennsylvania
10:45 The Categorical Abstract Machine, State of the Art
Pierre-Louis Curien, Ecole Normale Superieure, Paris VII
1:15 A Very Brief Look at NuPRL
Joseph Bates, Carnegie Mellon University
1:45 Reasoning about Programs that Construct Proofs
Robert Constable, Cornell University
2:30 Theorem Proving via Partial Reflection
Douglas Howe, Cornell University
3:15 MetaPrl: A Framework for Knowledge Based Media
Joseph Bates, Carnegie Mellon University
4:00 Discussion: The Role of Formal Reasoning in Software Development
5:00 Demos until 6:30
NuPRL in Wean Hall 4114 by Doug Howe
Lambda Prolog in WeH 4623 by Dale Miller, Gopalan Nadathur, and Amy Felty
Saturday, November 14
9:00 A Framework for Defining Logics
Robert Harper, Edinburgh University
9:45 The Logician's Workbench in the Ergo Support System
Frank Pfenning, Carnegie Mellon University
10:45 A Tactical Approach to Algorithm Design
Douglas Smith, Kestrel Institute
11:30 Reusing Data Structure Designs
Allen Goldberg, Kestrel Institute
1:15 Paddle: Popart's Development Language
David Wile, University of Southern California
2:00 Mechanizing Construction and Modification of Specifications
Martin Feather, University of Southern California
3:00 The TPS Theorem Proving System
Peter Andrews, Carnegie Mellon University
3:45 ONTIC: Knowledge Representation for Mathematics
David McAllester, Cornell University
4:30 Demos until 6:00
Popart and Paddle in the KBSA, Wean Hall 4114,
by David Wile and Martin Feather
The LF Proof Editor, Wean Hall 4623, by Robert Harper
∂16-Nov-87 1704 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu LICS competition
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Nov 87 17:03:56 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Mon 16 Nov 87 16:52:59-PST
Received: by lindy.stanford.edu; Mon, 16 Nov 87 16:55:42 PST
Received: by Forsythe.Stanford.EDU; Mon, 16 Nov 87 16:56:01 PST
Received: by NDSUVM1 (Mailer X1.24) id 3662; Mon, 16 Nov 87 17:30:12 CST
Date: 16 Nov 1987 18:19:50-EST (Monday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Ashok K. Chandra" <ASHOK@ibm.com>
Subject: LICS competition
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
LICS Cover and Logo Competition
Submissions are invited for the design of a cover for the
LICS proceedings, and a logo for the LICS symposium. It is
expected that one of the submissions will become the
standard cover for the LICS proceedings (for examples, see
the proceedings of the FOCS symposium, or the Structure in
Complexity Theory symposium). The logo is intended for use
in conference announcements.
The cover design should be 8" x 10", black on white, with
space to print the conference name and credits. The logo is
intended for use in approximately 2" x 2", and 1" x 1"
sizes, but submissions may be larger.
PRIZE: $100 for the winner of the cover competition, $50
for the logo winner. In addition, the names of the winners
will be acknowledged in the proceedings.
Artists should submit final or near-final designs to the
program chairman:
Yuri Gurevich - LICS competition
Electrical Engineering and Computer Science Department
University of Michigan
Ann Arbor, Michigan 48109-2122.
(313) 971-2652
Submissions should be sent by 15 December 1987.
Artists will be notified by 30 January 1988. Final designs
of winning entries will be due 14 March 1988. (All
submissions will become the property of the LICS conference.
Decisions of the LICS Program and Organizing committees will
be final).
BACKGROUND AND REMINDER: The third Logic in Computer
Science symposium will be held at the University of
Edinburgh, Scotland, JULY 5-8, 1988. Extended abstracts (14
copies) should be sent to Yuri Gurevich, postmarked by
NOVEMBER 27, or received by DECEMBER 4, 1987. The following
are some of the topics of interest at LICS: abstract data
types, computer theorem proving, concurrency, data base
theory, knowledge representation, finite model theory,
lambda and combinatory calculi, logic progarmming, modal and
temporal logics, program logic and semantics, software
specification, types and categories, constructive
mathematics, verification.
∂17-Nov-87 1103 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU Special Needs
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Nov 87 11:02:57 PST
Received: from Tenaya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 17 Nov 87 10:56:31-PST
Received: by Tenaya.Stanford.EDU (3.2/SMI-3.2)
id AA21610; Tue, 17 Nov 87 11:01:29 PST
Date: Tue, 17 Nov 87 11:01:29 PST
From: nilsson@Tenaya.Stanford.EDU (Nils Nilsson)
Message-Id: <8711171901.AA21610@Tenaya.Stanford.EDU>
To: faculty@score
Subject: Special Needs
In preparing the 88/89 budget, we should think about any special
departmental needs that we can now anticipate (TAs, special courses,
labs, etc.) I have asked Stuart Reges, Betty Scott, and George
Wheaton to think about these matters in light of previous budget
experiences and to provide advice about items that they foresee. If
any of you have suggestions please let me know---cc-ing Stuart.
Thanks, -Nils
∂17-Nov-87 1329 RICHARDSON@Score.Stanford.EDU A National Computing Initiative
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Nov 87 13:29:16 PST
Date: Tue 17 Nov 87 13:23:07-PST
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: A National Computing Initiative
To: faculty@Score.Stanford.EDU
Message-ID: <12351410289.43.RICHARDSON@Score.Stanford.EDU>
I have several copies of A NATIONAL COMPUTING INITIATIVE, The Agenda
for Leadership--Report of the Panel on Research Issues in Large-Scale
Computational Science and Engineering. Please feel free to come by my
office and browse through one.
-Anne
-------
∂17-Nov-87 1605 BSCOTT@Score.Stanford.EDU Annual Reports
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Nov 87 16:05:23 PST
Date: Tue 17 Nov 87 15:59:32-PST
From: Betty Scott <BSCOTT@Score.Stanford.EDU>
Subject: Annual Reports
To: AC@Score.Stanford.EDU
cc: BScott@Score.Stanford.EDU
Message-ID: <12351438762.32.BSCOTT@Score.Stanford.EDU>
Nils has suggested that the annual reports will be less burdensome for you to
complete if we complete all we can here, e.g., courses, units and enrollment,
and then send them out to you to check and fill in anything we have forgotten
or don't know about. Then you can have your secretary type the form and return
it to me.
We will start this project shortly.
Betty
-------
∂18-Nov-87 0250 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #87
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 18 Nov 87 02:50:06 PST
Date: Tue 17 Nov 1987 11:32-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #87
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Wednesday, 18 Nov 1987 Volume 5 : Issue 87
Today's Topics:
Announcement - Binding,
Query - SB Prolog & Wisdom Prolog,
Implementation - Badness
----------------------------------------------------------------------
Date: Tue 10 Nov 87 16:22:50-EST
From: vijay <Vijay.Saraswat@C.CS.CMU.EDU>
Subject: Bindings.
I have moved from the Computer Science Department at CMU to
the Intelligent Systems Lab at Xerox PARC. My new USMAIL and
net-address are:
Vijay Saraswat
Xerox PARC,
3333 Coyote Hill Road,
Palo Alto, Ca 9434.
(saraswat.pa@xerox.com)
------------------------------
Date: 12 Nov 87 04:52:33 GMT
From: cbosgd!cblpf!dtm@ucbvax.Berkeley.EDU (Dattaram Mirvke)
Subject: Sys V version of SB-prolog.
Recently I got a version SB-prolog. However it seems like it is
very much "in tune" with BSD UNIX. Has anyone hacked it to either get it
working on Sys V? May be you would like to save me and some others
here some work :-). Is there SysV version of this beast somewhere out there?
Thanks in advance..
------------------------------
Date: 12 Nov 87 21:41:19 GMT
From: ece-csc!drb@mcnc.org (Dr. Dennis R. Bahler)
Subject: Needed: views on Wisdom Prolog
I would like to hear from people who have impressions/experiences -- the
good, the bad, the ugly, and the indifferent -- with the Wisdom Prolog
available from MIT in connection with Sterling and Shapiro's book
The Art of Prolog. Specifically, (i) how suitable/friendly is it for advanced
undergraduates with no logic programming experience? (ii) how does it compare
with other such systems? (iii) any known major plusses/deficiencies?
Pointers to written reviews would also be appreciated.
We have someone here who is thinking about using this system in an
advanced undergrad languages course that also does LISP, Smalltalk-V, etc.
He has IBM PC's to play with.
-- Dennis Bahler
------------------------------
Date: 11 Nov 87 00:27:31 GMT
From: blenko@burdvax.prc.unisys.com (Tom Blenko)
Subject: Re: Badness
It isn't clear what the admonition to program declaratively means.
Programming declaratively, in the sense of pure PROLOG (without call(),
not(), and cut()) is not even powerful enough to express IF-THEN-ELSE,
which I am willing to assume is a _sine_qua_non_ for programming. One
can get IF-THEN-ELSE back with call() and not(), but the
non-declarative character of PROLOG not() is also well known. So I
don't think we can take "program declaratively" too seriously if it
means that we cannot express IF-THEN-ELSE (because it doesn't suffice
as programming), or if it means that we have to admit call() and not()
(because then it isn't declarative).
Just to save some time here, I also point out that not() restricted to,
or delayed to await, grounded arguments, as you and others have
proposed, does not get one out of the difficulty (of expressing
IF-THEN-ELSE declaratively when the condition requires more than
constructor matching).
I'm not sure we're disagreeing. I do recall a perfectly fine
declarative program for append3() that you cite in a paper as suffering
from non-termination, even though correct declarative solutions are
also possible, and other examples are not too hard to come by. So I
think the "program declaratively" admonition is not even safe,
efficiency questions aside.
-- Tom
------------------------------
Date: Mon, 9 Nov 87 12:16:35 GMT
From: Fernando Pereira <pereira%cam.sri.com@drakes.ai.sri.com>
Subject: Blenko's defence of mediocrity
Tom Blenko says
> ... Most code, Prolog
> and otherwise, is good enough because it runs. Programmers have
> neither the time nor the interest to engage in the pensive, reflective
> approach to programming that O'Keefe espouses.
Is he this understanding of mediocrity with respect to products he
may buy, a new car, say? Is he happy enough with a car just because it
runs when he buys it? What about when it doesn't start in a particularly
wet/cold day? Will he accept an excuse from the manufacturer along the
lines ``do you expect us to test cars under conditions that only happen
once every two years?'' And what about economy, comfort, and so on?
``Good enough because it runs'' is the standard excuse of mediocre
engineering. We know what this attitude to quality has done to
US industry...
I don't see why a computer program should be any less well designed
than a [good] car. Yet software manufacturers as a matter of course
put out products of a standard of quality that consumers would not
tolerate in a car or VCR. No commercial program that I have bought
for myself or my company breaks down as rarely as my five-year-old
economy model German car. The thoughtful approach to quality that
Richard O'Keefe advocates is essential in good manufacturing, as
the many books and articles written recently about Japan's industrial
success make exceedingly clear.
As for append/3: if Tom's complaint is that it does not check whether
its second argument is a list, the real question is ``why should it?''
That definition of append satisfies the specification
(forall x y z) (list(x) & list(y) & append(x,y,z) =>
list(z) & x::y = z)
where :: is the list concatenation function. What is the problem if
append(x,y,z) accepts certain nonlist arguments? IF what Tom wants is
the stricter specification
(forall x y z) (append(x,y,z) => list(x) & list(y) & list(z) &
x::y = z)
he won't have any difficulty in implementing it (at a cost!).
-- Fernando Pereira
------------------------------
Date: 12 Nov 87 21:16:30 GMT
From: broome@smoke.brl.mil (Paul Broome )
Subject: Badness
It's not clear that IF-THEN-ELSE is essential for programming. In fact it's
often hazardous! The ELSE part of an IF-THEN-ELSE is too all-enclosing.
A small example that immediately comes to mind is factorial, often written
something like
fac(N) = if N=0 then 1
else N*fac(N-1).
The danger comes from permitting an unbounded recursion for negative N.
It's much better, in this case at least, to say explicitly what cases
can be handled and fail for those outside. E.g. something like
fac(N) = if N=0 then 1
if N>0 then N*fac(N-1).
It would be interesting to see a small example that *requires* IF-THEN-ELSE?
-- Paul
------------------------------
Date: Mon, 9 Nov 87 22:22:33 PST
From: quintus!ok@Sun.COM (Richard A. O'Keefe)
Subject: Badness
Tom Blenko writes "Programmers have neither the time nor the
interest to engage in the pensive, reflective approach to
programming that O'Keefe espouses." (It really is VERY kind of
kind to say that I "espouse" this approach, but how can he know
that?) Let me paraphrase that:
Programmers have neither the time nor the interest to do
the job they are paid to do. Let the customer pay!
I bank with the XYZ bank. Their computer seems to crash an
awful lot, and they told me that I couldn't add my father's name
to my account, I'd have to close the old account and open a new
one. Sounds as though they have some programmers who have
neither the time nor the interest to think about their programs.
I was once given a piece of advice about flying: "[when something
goes wrong] don't just DO something, SIT THERE [and think about it
first]". If this is good advice for someone whose plane has started
spinning towards the ground, can the pressures on programmers really
be so much worse that they have to do something without thinking?
There *is* a difference: if a pilot crashes his plane, HE suffers,
but if a programmer's program crashes, it's often someone ELSE who
suffers.
Surely someone who is paid to write programs has a duty to think
about what s/he is doing. And with respect to textbooks, someone
who is paid to tell other people how to write programs also has a
duty to think about what s/he is doing.
Tom Blenko says that "goodness (and even correctness) of software
depends upon one's perspective." Sure. Just like whether 1+2 = 3
depends on one's perspective. A piece of software is correct if and
only if it satisfies its specification. In the case of Lagache's
library, for example, the specification was the documentation written
in English. And the code did not satisfy its specification. I was
able to show that there were calls (such as calling the sort routine
with a variable as first argument) which the documentation did not
prohibit which did not behave sensibly. I did say that the code
probably worked in the context that Lagache intended, but it is a
plain matter of fact that his documentation did not say what all the
restrictions on his code were. Either the code or the specification
could be changed to produce correct software, but that does not mean
that the incompatibility of the code and specification that existed
depends on anyone's perspective. Similarly, goodness is objective.
A tool (and a subroutine library is a tool) is good to the extent
that it is fit for its intended purpose. In the case of software,
we can measure
size of program
speed
space use
quite easily. With some effort, we can measure (on an ordinal scale)
how easy the code is to read, maintain, or adapt to a slightly
different task.
Blenko claims that the usual definition of append/3 is
"erroneous Prolog software" and gibes that he has never "seen a
correct version (even in the Quintus library!)". Wrong. The
definition of append/3 simply IS. It can only be correct or
erroneous with respect to a particular specification. I'm not
contradicting myself here: correctness is a relation between a
program and a specification, and for a given specification the
correctness or otherwise of a program is an objective fact.
The specification we at Quintus use is that append/3 is only
defined when the arguments are lists. (In fact the DEC-10
Prolog type checker has the meta-fact
:- pred append(list(T),list(T),list(T)).
which makes this explicit.) The usual definition of append/3
is correct with respect to that specification. It is easy to
give a specification with respect to which it is incorrect:
"append(X, Y, Z) is true when X, Y, and Z are integers
and Z is congruent to (X+Y) modulo 42".
There's nothing special about append/3: the usual definition
of member/1 entails the satisfiability of member(1, .(1,fred)).
So what? It's correct if that behaviour is consistent with the
specification, and if the specification only says what happens
when the second argument is (or may become) a list, fine.
With respect to Blenko's numbered points, I have to agree.
Though his point 1 really amounts to saying that some people
writing "Prolog" are really writing Lisp and neither know nor care.
But I must take issue with this point 5, which I repeat here.
5. It is well known that O'Keefe's and Naish's exhortations
to Lagache (for sensitivity to efficiencies in the
implementation and for conformity to simple declarative
interpretations) will sometimes conflict. This presents
the programmer with a dilemma that he or she may not
(indeed may not be able to) escape.
One of the files in the public-domain DEC-10 Prolog library is
called ORDSET.PL. It defines set operations, using lists in standard
order without duplicates as the representation of sets. The Quintus
library includes a file ordsets.pl which adds some operations and
fixes some bugs, but was essentially the same. I have just finished
rewriting nearly every predicate in that file. The new code
contains no cuts
has no overlapping clause heads
is 15% to 20% faster.
Conflict? Dilemma? Not this time. Not often, either.
I'm beginning to think that it may not be Prolog after all. Someone
recently sent me a draft of a paper. The paper compares versions of a
program in four declarative languages (including Prolog) and Pascal.
It was most illuminating. I wouldn't describe any of the versions as
"bad". But there was a subtle difference between the declarative
versions and the Pascal version which rendered the (storage cost)
comparison invalid. I'm not going to go into details; that's for the
author of the paper to do. But a key lesson I learned from it is that
it can be appallingly hard to get any idea of what a program in a
lazy functional language or a language like FP is up to. Subtle
differences in the code can have dramatic effects on efficiency (I
identified a *possible* time factor of 20 in one program and an
*actual* space factor of 30 in another). There is a new book by Simon
Peyton-Jones about functional languages. He has a chapter on pragmatics,
and there are some really unpleasant subtleties. I'm inclined to think
that lazy evaluation is much harder to understand than backtracking.
The difference between a lazy program which constructs only part of an
infinite data structure and one which races off to infinity may be very
hard to see in the source code.
Is there a greater tendency for Prolog programmers to write bad
Prolog than for Scheme programmers to write bad Scheme? Than for
Miranda programmers (or KRC or SASL or whatever)? What we need here
is some input from people who are teaching at least two declarative
languages.
------------------------------
End of PROLOG Digest
********************
∂18-Nov-87 1041 ALPERT@Score.Stanford.EDU FRAME MAKER publishing demo
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 18 Nov 87 10:41:48 PST
Date: Wed 18 Nov 87 10:34:27-PST
From: Jack Alpert <ALPERT@Score.Stanford.EDU>
Subject: FRAME MAKER publishing demo
To: csd@Score.Stanford.EDU, staff@Score.Stanford.EDU,
faculty@Score.Stanford.EDU, G.gorin@Macbeth.Stanford.EDU
cc: alpert@Score.Stanford.EDU
Message-ID: <12351641727.38.ALPERT@Score.Stanford.EDU>
FRAME MAKER -- Jennifer Garrison from FRAME TECHNOLOGY will be at CSD on Monday
November 23 at 1:30 PM, rm 030 MJH to give a demonstration of "FRAME MAKER."
RSVP if you are coming to the demo.
A demo copy of Frame Maker exists on the Jeeves file server and
YOU CAN HAVE YOUR OWN COPY of the demo software. HOWEVER I have only one
Reference Manuel and User's Guide. Contact Dan Kolkowitz for software access.
INTERLEAF -- A demo copy of Interleaf which allows adding up to 5 additional
workstations has arrived and will be put up on JEEVES by Monday November 16.
If you want to have your Sun enabled. Please send your host ID to
Kolkowitz@score. This offer is limited. Alpert@score for details. I have
received one copy of the Interleaf Reference Manuals.
ARBOR TEXT -- In mid- November I will receive a copy of ARBOR TEXT. I have not
seen it but I understand it is a two window system. In one widow is an ASCII
character file with tex or latex commands and text. The other window is an
updateable preview window.
Jack Alpert 723-1096
-------
∂18-Nov-87 1122 barwise@russell.stanford.edu note of interest
Received: from RUSSELL.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 18 Nov 87 11:22:36 PST
Received: from localhost by russell.stanford.edu (3.2/4.7); Wed, 18 Nov 87 11:17:59 PST
To: ssp-faculty@russell.stanford.edu, ssp-students@russell.stanford.edu
Subject: note of interest
Date: Wed, 18 Nov 87 11:17:58 PST
From: barwise@russell.stanford.edu
I just received (via John Perry) an announcement of a graduate program
(masters) in Philosophy and Computer systems sciences, from SUNY at
Binghamton. They are also advertising for faculty in the program.
I will give them to Margie in case any of you are interested in seeing
them.
Van, You might want to look at the Master's program in connection with
your effort.
Jon
∂18-Nov-87 1429 barwise@russell.stanford.edu another ssp-type program that might interest you
Received: from RUSSELL.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 18 Nov 87 14:29:49 PST
Received: from localhost by russell.stanford.edu (3.2/4.7); Wed, 18 Nov 87 13:44:51 PST
To: ssp-faculty@russell.stanford.edu, ssp-students@russell.stanford.edu
Subject: another ssp-type program that might interest you
Date: Wed, 18 Nov 87 13:44:49 PST
From: barwise@russell.stanford.edu
COGNITIVE SCIENCE
University of California, San Diego
The University of California, San Diego is considering the
establishment of a Department of Cognitive Science and is
seeking candidates for tenured or tenure-track positions
at the Assistant Professor, Associate Professor, and
Professor levels.
The Department will take a broadly-based approach to the
study of cognition. It will be concerned with the neurolog-
ical basis of cognition, individual cognition, cognition
in social groups, and machine intelligence. It will incor-
porate methods and theories from a wide variety of dis-
ciplines including Anthropology, Computer Science,
Linguistics, Neuroscience, Philosophy, Psychology, and
Sociology.
We intend to develop a new curriculum for both
undergraduate and graduate students and applicants
should be interested in participating in the con-
struction of new approaches to the study and teach-
ing of cognition. We seek people whose interests cut
across conventional disciplines. Interests in theory,
computational modeling (especially PDP), application,
and education are encouraged.
Candidates should send a vita, reprints, a short letter
describing their background and interests, and names of at
least three references to:
Search Committee
Cognitive Science, C-015-v
University of California, San Diego
La Jolla, CA 92093
Applications received prior to January 15 will be given the
fullest consideration, however applications will be accepted
until all positions are filled. Rank and salary will
be commensurate with experience and qualifications, and
will be based upon UC pay schedules.
Women and minorities are especially encouraged to
apply. The University of California, San Diego is an
Affirmative Action/Equal Opportunity Employer.
- -------
------- End of Forwarded Message
∂18-Nov-87 1527 TAJNAI@Score.Stanford.EDU Small Business Membership - a member
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 18 Nov 87 15:27:11 PST
Date: Wed 18 Nov 87 15:20:11-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Small Business Membership - a member
To: faculty@Score.Stanford.EDU
Message-ID: <12351693745.36.TAJNAI@Score.Stanford.EDU>
Dr. John R. Koza joined the Forum under the new category of
small business. ADS has committed for January 1, and there
are others who are considering it.
As a reminder, companies who have fewer than 500 employees may join
the Forum for $9,000/year. Let me know if there is someone you want
me to contact. Faculty still receive a finder's fee for small
business members ($1500/year for first 3 years of membership).
Carolyn
-------
∂18-Nov-87 1610 TAJNAI@Score.Stanford.EDU Poster Sessions and Demos at the Forum
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 18 Nov 87 16:10:38 PST
Date: Wed 18 Nov 87 16:01:02-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Poster Sessions and Demos at the Forum
To: faculty@Score.Stanford.EDU
cc: cornelius@SUMEX-AIM.Stanford.EDU
Message-ID: <12351701180.36.TAJNAI@Score.Stanford.EDU>
We are planning a poster session and a few demos
Wednesday, Feb. 10 from 1:30 to 3:45 in the CERAS lobby.
Craig Cornelius will chair this session.
We will have individual stand-alone boards on which students
can put posters. They will man their posters during the session
and answer questions. It is a good time for MS students to gain
exposure and also PHD students who are not far enough along to
give formal talks.
We will also have 4 to 6 demonstrations.
If you have students who would be interested in participating in
this new and special session, please notify either Craig or me.
Cornelius@sumex.
Carolyn
-------
∂18-Nov-87 1900 LOGMTC-request Seminar in Logic
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 18 Nov 87 18:59:58 PST
Date: Wed 18 Nov 87 18:53:40-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: Seminar in Logic
To: logmtc@Sail.Stanford.EDU
Message-ID: <12351732607.12.SF@CSLI.Stanford.EDU>
Seminar in Logic and Foundations
Phokion Kolaitis will continue to talk about the work of Immerman
on global inductive definitions on finite models.
Monday, Nov. 23, 4:15-5:30, Room 380-T, Stanford.
S. Feferman
-------
∂19-Nov-87 1030 TAJNAI@Score.Stanford.EDU [Arthur Keller <ARK@SAIL.Stanford.EDU>: Re: Small Business Membership - a member]
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 19 Nov 87 10:30:09 PST
Date: Thu 19 Nov 87 10:23:21-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: [Arthur Keller <ARK@SAIL.Stanford.EDU>: Re: Small Business Membership - a member]
To: faculty@Score.Stanford.EDU
Message-ID: <12351901851.24.TAJNAI@Score.Stanford.EDU>
---------------
Return-Path: <ARK@SAIL.Stanford.EDU>
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 18 Nov 87 17:18:35-PST
Date: 18 Nov 87 1723 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: Small Business Membership - a member
To: tajnai@Score.Stanford.EDU
Dr. John R. Koza joined the Forum under the new category of
small business. ADS has committed for January 1, and there
are others who are considering it.
As a reminder, companies who have fewer than 500 employees may join
the Forum for $9,000/year. Let me know if there is someone you want
me to contact. Faculty still receive a finder's fee for small
business members ($1500/year for first 3 years of membership).
Carolyn
-------
It wasn't totally clear, but I assume ADS (Adv. Dec. Sys.) is joining
starting Jan 1, with Dr. John R. Koza as the liaison, right?
Arthur
..........
CLARIFICATION: Sorry if my message was not clear.
Dr. John Koza, who is in the process of setting up a new venture capital
firm, joined the Forum under the small business category on Nov. 18.
On Jan. 1, Advanced Desicions Systems will also join. That will make
two companies in that category.
Carolyn
-------
∂19-Nov-87 1205 emma@russell.stanford.edu CSLI Calendar, November 19, 3:8
Received: from RUSSELL.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 19 Nov 87 12:05:21 PST
Received: from localhost by russell.stanford.edu (3.2/4.7); Thu, 19 Nov 87 11:23:02 PST
Date: Thu, 19 Nov 87 11:22:44 PST
From: emma@russell.stanford.edu
Subject: CSLI Calendar, November 19, 3:8
------- Blind-Carbon-Copy
To: friends
Subject: CSLI Calendar, November 19, 3:8
Date: Thu, 19 Nov 87 11:22:44 PST
From: emma
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
19 November 1987 Stanford Vol. 3, No. 8
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 19 November 1987
12 noon TINLunch
Ventura Hall No TINLunch
Conference Room
2:15 p.m. CSLI Seminar
Room G-19 Anaphora and Linking Theory
Redwood Hall Paul Kiparsky (kiparsky@csli.stanford.edu)
Abstract below
3:30 p.m. Tea
Ventura Hall
--------------
CSLI ACTIVITIES FOR THURSDAY, 3 December 1987
12 noon TINLunch
Ventura Hall No TINLunch
Conference Room
2:15 p.m. CSLI Seminar
Room G-19 FOG and Related Activities
Redwood Hall Martin Kay (Kay.pa@xerox.com)
Hans Uszkoreit
Lauri Karttunen (Karttunen.pa@xerox.com)
3:30 p.m. Tea
Ventura Hall
4:15 p.m. CSLI Colloquium
Where Computerized Visual Communication for Aphasics
or Linguistics in Thought and Action
Michael Weinrich and Dick Steele
Department of Neurology
Stanford University School of Medicine
Abstract below
--------------
ANNOUNCEMENT
There will be no activities next Thursday, 26 November, because of
Thanksgiving.
--------------
THIS WEEK'S CSLI SEMINAR
Anaphora and Linking Theory
Paul Kiparsky
(Kiparsky@csli.stanford.edu)
November 19, 1987
Linking theory is about how syntax, morphology, and the lexicon
express relations between predicates and their arguments. In this
talk we develop some of its consequences for the theory of anaphora.
Specifically, we propose an account for the following properties of
anaphor binding: (1) the partitioning of binding principles among two
levels of representation, lexical structure and surface structure; (2)
the parametrization of "subject" (grammatical/logical) and the
sensitivity of anaphora to Th-roles; (3) the dependence of the binding
behavior of anaphors on their morphological shape, e.g., why strict
subject-orientation and long-distance anaphora are found only in
non-lexical reflexives; (4) cross-linguistic patterns of hononymy,
e.g., which kinds of reflexives double as passives and which as
antipassives.
--------------
CSLI COLLOQUIUM
Computerized Visual Communication for Aphasics
or Linguistics in Thought and Action
Michael Weinrich and Dick Steele
Department of Neurology, Stanford University School of Medicine
December 3, 1987
The language of aphasic patients has long been a fertile, if somewhat
controversial, ground for the generation of linguistic theories
regarding the comprehension and production of language. We present
here some results of a new approach to the treatment of chronic,
severe aphasics. In this approach, a visual interface is used to
communicate with patients. The interface contains lexical items,
tools for manipulating them, and is operated following a set of simple
syntactic rules. We will discuss some of the implications of our
results for neurolinguistic theories. The issues central to the
design of the interface, i.e., representations of lexical items and
situational knowledge, and the effects of different representation on
pragmatic use, will be discussed.
------- End of Blind-Carbon-Copy
∂20-Nov-87 1300 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: Sanitary surgeons and safe sex.
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Nov 87 13:00:01 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Fri 20 Nov 87 12:50:51-PST
Received: by lindy.stanford.edu; Fri, 20 Nov 87 12:53:49 PST
Received: by Forsythe.Stanford.EDU; Fri, 20 Nov 87 12:54:20 PST
Received: by NDSUVM1 (Mailer X1.24) id 8088; Thu, 19 Nov 87 11:59:01 CST
Date: 18 Nov 1987 11:50:34-EST (Wednesday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Vladislav Rutenburg <RUTENBURG@score.stanford.edu>
Subject: Re: Sanitary surgeons and safe sex.
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
A small correction. The problem has been in existence long before 1978. In
particular, I had learned it in 1986 from a friend who had known it for
another 5 to 10 years from the Odessa, USSR math olympiad circles. In fact,
he first told me the safe sex version of it and immediately added: ''But, of
course, the Olympiad people phrazed it in the surgeon form for decency reasons.
". i am sure, there is somebody from Odessa who can trace how the problem got
to Odessa in the first place. I would not be surprized if it were more than
30 years old and had appeared in some earlier puzzle book.
--Vlad
∂20-Nov-87 1411 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu On the complexity of maintaining partial sums
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Nov 87 14:11:21 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Fri 20 Nov 87 14:03:54-PST
Received: by lindy.stanford.edu; Fri, 20 Nov 87 14:06:59 PST
Received: by Forsythe.Stanford.EDU; Fri, 20 Nov 87 14:07:40 PST
Received: by NDSUVM1 (Mailer X1.24) id 9274; Thu, 19 Nov 87 12:43:28 CST
Date: 18 Nov 1987 13:11:39-EST (Wednesday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Victor S. Miller" <VICTOR%YKTVMZ.BITNET@forsythe.stanford.edu>
Subject: On the complexity of maintaining partial sums
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
Given an array A(i) initialized to 0, we consider a sequence of operations
UPDATE(a,i): add a to A(i)
QUERY(j): return sum(i=1 to j) A(i)
It is fairly easy to see that if the number of elements of the array
is N and the number of operations is M, we can do it in time O(M log N)
(by building a binary tree of intermediate partial sums, for example).
In a paper "On the Complexity of Maintaining Partial Sums" (published
as IBM Tech Rept RJ3228, and probably elsewhere, but I don't know the
reference), Andrew Yao showed that there is a lower bound of
Omega (N log N / log log N) if M = O(N). This result dated from 1981.
Has there been any progress on tightening the upper and lower bounds
since then?
Victor Miller -- IBM Research
∂20-Nov-87 1446 SARAIYA@SUMEX-AIM.STANFORD.EDU Wed, 11/25, 9am: AIRTRAC design review
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Nov 87 14:46:46 PST
Date: Fri, 20 Nov 87 14:45:29 PST
From: Nakul P. Saraiya <SARAIYA@SUMEX-AIM.STANFORD.EDU>
Subject: Wed, 11/25, 9am: AIRTRAC design review
To: aap@SUMEX-AIM.STANFORD.EDU
Message-ID: <12352211715.78.SARAIYA@SUMEX-AIM.STANFORD.EDU>
Next Wednesday's meeting is scheduled to be a design review of the
path association module for AIRTRAC. It starts at 9am in the WR
conference room.
The presenters will be Alan Noble & Chris Rogers.
Nakul
-------
∂20-Nov-87 1621 STAGER@Score.Stanford.EDU Tau Beta Pi course surveys
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Nov 87 16:21:37 PST
Date: Fri 20 Nov 87 16:13:02-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: Tau Beta Pi course surveys
To: instructors@Score.Stanford.EDU, tas@Score.Stanford.EDU
cc: jimenez@Score.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12352227652.20.STAGER@Score.Stanford.EDU>
Tau Beta Pi course survey instruction sheets, forms, pencils, and return
envelopes have been delivered. Please see Tina Jimenez (or send a message
or your TA...)in CS-TAC for your survey materials.
Thanks again for your cooperation.
Claire
-------
∂20-Nov-87 1725 SARAIYA@SUMEX-AIM.STANFORD.EDU PhD Orals
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Nov 87 17:25:23 PST
Return-Path: <VINEET@score.stanford.edu>
Received: from labrea.stanford.edu by SUMEX-AIM.STANFORD.EDU with TCP; Tue, 17 Nov 87 23:13:15 PST
Received: from Score.Stanford.EDU by labrea.stanford.edu with TCP; Tue, 17 Nov 87 23:03:46 PST
Date: Tue 17 Nov 87 22:59:58-PST
From: Vineet Singh <VINEET@score.stanford.edu>
Subject: PhD Orals
To: su-events@score.stanford.edu
Message-Id: <12351515301.12.VINEET@Score.Stanford.EDU>
ReSent-Date: Fri, 20 Nov 87 17:24:39 PST
ReSent-From: Nakul P. Saraiya <SARAIYA@SUMEX-AIM.STANFORD.EDU>
ReSent-To: AAP@SUMEX-AIM.STANFORD.EDU
ReSent-Message-ID: <12352240689.78.SARAIYA@SUMEX-AIM.STANFORD.EDU>
"Distributing Backward-Chaining Deductions to Multiple Processors"
by Vineet Singh
at 2:15 pm
on November 24 (Tuesday)
in AEL 109
Abstract:
Effective allocation of resources in a multiprocessor can make a
dramatic improvement in the execution time. Optimal allocation is
impractical because even simplistic computation and multiprocessor
models make the problem NP-complete or worse. This thesis presents an
effective, sub-optimal allocation strategy for backward-chaining
deduction on a practical multiprocessor.
The target class of multiprocessors for this dissertation satisfies
the following properties: (1) there are a finite number of processors;
(2) each processor has a finite amount of local memory; (3) there is
no global memory; (4) processors are connected with some scaleable
interconnection topology; (5) processors can communicate only by
sending messages to each other; (6) message delay is some non-zero
monotonic function of the amount of data in the message and the
distance between source and destination; (7) each processor can
perform backward-chaining deductions based on the subset of the
program that it contains.
Sequential execution models for backward-chaining deduction with horn
clauses, used in sequential logic programming languages, are not
suitable for multiprocessors. I present a parallel execution model
called PM. For the same multiprocessor class, PM can exploit the most
parallelism among execution models that use data-driven control. In
particular, PM can exploit or-parallelism, and-parallelism, and
pipelining.
The proposed allocation strategy needs some restrictions that PM does
not require. First, the type of backward-chaining deduction is
restricted. In particular, no recursive clauses are allowed, unit
clauses must be ground, and certain probabilistic uniformity and
independence assumptions must apply. Second, allocation is restricted
to be done at compile-time (as opposed to run-time). Third, a
partitioning of the database is assumed to be given.
The allocator consists of an initial allocation phase followed by a
local optimization phase. In the initial allocation phase, database
partitions are allocated to processors one at a time using a greedy
algorithm. The local optimization phase consists of a sequence of
cost-reducing reallocations of partitions to neighboring processors.
Both greedy and local minimization are based on a formally defined cost
function. This cost function quantifies intuitive notions of undesirable
allocations. Algorithms are presented for the efficient computation
and recomputation of this cost function.
Considerable speedups are obtained by using this allocation strategy.
These speedups compare favorably with an unreachable upper bound and
speedups obtained using random allocations.
-------
∂21-Nov-87 0042 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for Papers - International Neural Netowrk Society
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 Nov 87 00:40:47 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Sat 21 Nov 87 00:34:38-PST
Received: by lindy.stanford.edu; Sat, 21 Nov 87 00:37:28 PST
Received: by Forsythe.Stanford.EDU; Sat, 21 Nov 87 00:37:52 PST
Received: by NDSUVM1 (Mailer X1.24) id 4756; Fri, 20 Nov 87 22:33:25 CST
Date: 20 Nov 1987 15:48:42-EST (Friday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Michael Cohen <MIKE%BUCASB.BU.EDU@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Michael Cohen <MIKE%BUCASB.BU.EDU@forsythe.stanford.edu>
Subject: Call for Papers - International Neural Netowrk Society
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
INTERNATIONAL NEURAL NETWORK SOCIETY
1988 ANNUAL MEETING
September 6--10, 1988
Boston, Massachusetts
The International Neural Network Society (INNS) invites all
those interested in the exciting and rapidly expanding field of
neural networks to attend its 1988 Annual Meeting. The meeting
includes plenary lectures, symposia, contributed oral and poster
presentations, tutorials, commercial and publishing exhibits, a
placement service for employers and educational institutions,
government agency presentations, and social events.
---INNS OFFICERS AND GOVERNING BOARD---
Stephen Grossberg, President; Demetri Psaltis, Vice-President;
Harold Szu, Secretary/Treasurer.
Shun-ichi Amari, James Anderson, Gail Carpenter, Walter Freeman, Kunihiko
Fukushima, Lee Giles, Teuvo Kohonen, Christoph von der Malsburg, Carver Mead,
David Rumelhart, Terrence Sejnowski, George Sperling, Bernard Widrow.
---MEETING ORGANIZERS---
General Meeting Chairman: Bernard Widrow
Technical Program Co-Chairmen: Dana Anderson and James Anderson
Organization Chairman: Gail Carpenter
Tutorial Program Co-Chairmen: Walter Freeman and Harold Szu
Conference Coordinator: Maureen Caudill
---SPEAKERS---
Plenary:
Stephen Grossberg
Carver Mead
Terrence Sejnowski
Nobuo Suga
Bernard Widrow
Cognitive and Neural Systems:
James Anderson
Walter Freeman
Christoph von der Malsburg
David Rumelhart
Allen Selverston
Vision and Pattern Recognition:
Gail Carpenter
Max Cynader
John Daugman
Kunihiko Fukushima
Teuvo Kohonen
Ennio Mingolla
Eric Schwartz
George Sperling
Steven Zucker
Combinatorial Optimization and Content Addressable Memory:
Daniel Amit
Stuart Geman
Geoffrey Hinton
Bart Kosko
Applications and Implementations:
Dana Anderson
Michael Buffa
Lee Giles
Robert Hecht-Nielsen
Demetri Psaltis
Thomas Ryan
Bernard Soffer
Harold Szu
Wilfrid Veldkamp
Motor Control and Robotics:
Jacob Barhen
Daniel Bullock
James Houk
Scott Kelso
Lance Optican
---ABSTRACTS---
Submit abstracts for oral and poster presentation on biological and
technological models of:
--Vision and image processing
--Local circuit neurobiology
--Speech and language
--Analysis of network dynamics
--Sensory-motor control and robotics
--Combinatorial optimization
--Pattern recognition
--Electronic implementation (VLSI)
--Associative learning
--Optical implementation
--Self-organization
--Neurocomputers
--Cognitive information processing
--Applications
Abstracts must be typed on the INNS abstract form in camera-ready format.
Request abstracts from: INNS Conference, 16776 Bernardo Center Drive,
Suite 110B, San Diego, CA 92128 USA. INNS members will be directly sent
an abstract form.
----------ABSTRACT DEADLINE: MARCH 31, 1988----------
Acceptance notifications will be mailed in June, 1988. Accepted abstracts
will be published as a supplement to the INNS journal, Neural Networks,
and mailed to meeting registrants and Neural Networks subscribers in
August, 1988.
---PROGRAM COMMITTEE---
Joshua Alspector Teuvo Kohonen
Shun-ichi Amari Bart Kosko
Dana Anderson Daniel Levine
James Anderson Richard Lyon
Jacob Barhen Ennio Mingolla
Michael Buffa Paul Mueller
Daniel Bullock Lance Optican
Terry Caelli David Parker
Gail Carpenter Demetri Psaltis
Michael Cohen Adam Reeves
Max Cynader Thomas Ryan
John Daugman Jay Sage
David van Essen Eric Schwartz
Federico Faggin Allen Selverston
Nabil Farhat George Sperling
Walter Freeman David Stork
Kunihiko Fukushima Harold Szu
Lee Giles David Tank
Stephen Grossberg Wilfrid Veldkamp
Morris Hirsch Bernard Widrow
Scott Kelso
---PARTICIPATING SOCIETIES---
American Mathematical Society; Cognitive Science Society; Optical Society
of America; Society for Industrial and Applied Mathematics; Society of
Photo-Optical Instrumentation Engineers; and others pending.
---TUTORIALS---
Tutorials will consist of eight one-hour introductory lectures by distinguished
scientists. The lectures will help prepare the audience for the more advanced
presentations at the meeting. The tutorial topics include:
1. Vision and image processing
2. Pattern recognition, associative learning, and self-organization
3. Cognitive psychology for information processing
4. Local circuit neurobiology
5. Adaptive filters
6. Nonlinear dynamics for brain theory (competition, cooperation, equilibria,
oscillations, and chaos)
7. Applications and combinatorial optimization
8. Implementations (electronic, VLSI, and optical neurocomputers)
Tutorials will be held on Tuesday, September 6, 1988, from 8AM to 6PM. The
general conference will begin with a reception at 6PM, followed by the
conference opening and a plenary lecture.
---REGISTRATION AND HOTEL---
Fill out attached forms.
Registration fees partially pay for abstract handling, the books of abstracts,
two evening receptions, coffee breaks, mailings, and administrative expenses.
---TRAVEL---
Call UNIGLOBE (800) 521-5144 or (617) 235-7500 to get discounts of up to 65%
off coach fares.
---COMMERCIAL AND GOVERNMENT FUNCTIONS---
Conference programs have been designed for commercial vendors, government
agencies and research laboratories, publishers, and educational institutions.
These include a large exhibit area (the Boston Park Plaza Castle); a placement
service for employment interviews; catered hospitality suites; and special
presentations. A professional exposition service contractor will carry out
exhibit arrangements. Organizations wishing to be put on a mailing list for
participants in these programs should fill out the enclosed form.
---STUDENTS AND VOLUNTEERS---
Students are welcome to join INNS and to participate in its meeting. See
attached forms for reduced registration, tutorial, and membership fees.
Financial support is anticipated for students and meeting volunteers. To
apply, attach a letter of request and a brief description of interests to
the conference registration form.
****************************** cut here ******************************
---CONFERENCE AND TUTORIAL REGISTRATION FORM---
1988 ANNUAL MEETING
INTERNATIONAL NEURAL NETWORK SOCIETY
September 6--10, 1988
Boston, Massachusetts
Name:
Organization:
Address:
Telephone(s):
Conference Registration Fee Schedule: CIRCLE ONE
September 6, 1988 (6 PM) -- September 10, 1988 (5 PM)
INNS Member Non-member
Until March 31, 1988 $125 $170(*)
Until July 31, 1988 $175 $220(*)
Full-time student $50 $85(*)
(*) Includes 1987--1988 INNS membership and 1-year subscription to the INNS
journal, Neural Networks. A membership application form is enclosed.
Tutorial Registration Fee Schedule: CIRCLE ONE
Tuesday, September 6, 1988 (8 AM -- 6 PM)
Note: Tutorial attendees must also register for the conference
INNS INNS
Regular Member Student Member
Until March 31, 1988 $100 $30
Until July 31, 1988 $150 $60
Check or money order enclosed, made payable to INNS.
Or charge:
( ) American Express
( ) MasterCard
( ) VISA
Account No.:
Expiration Date:
Signature _____________________________________________________
MAIL TO: UNIGLOBE---Neural Networks 1988
40 Washington Street
Wellesley Hills, MA 02181 USA
(800) 521-5144
(617) 235-7500
****************************** cut here ******************************
---ABSTRACT REQUEST FORM---
INTERNATIONAL NEURAL NETWORK SOCIETY
1988 ANNUAL MEETING
September 6--10, 1988
Boston, Massachusetts
NOTE: Abstract forms and instructions will be mailed to INNS members and
to those who have already sent in a request by January, 1988.
Please send an abstract form and instructions to:
Name:
Address:
Telephone(s):
All abstracts must be submitted camera-ready, typed on the INNS abstract form
and postmarked no later than March 31, 1988.
---MAILING LIST---
COMMERCIAL, NON-PROFIT, AND GOVERNMENT ORGANIZATIONS
Please place the name and address listed above on a mailing list for
information about exhibits, placement services for employment interviews,
hospitality suites, and related programs.
( ) Commercial Vendor
( ) Government
( ) Non-profit Corporation
( ) Publisher
( ) Educational Institution
( ) Other (please specify)
MAIL TO: INNS Conference
16776 Bernardo Center Drive
Suite 110B
San Diego, CA 92128 USA
INQUIRIES: (619) 451-3752
****************************** cut here ******************************
---HOTEL RESERVATION FORM---
INTERNATIONAL NEURAL NETWORK SOCIETY
1988 ANNUAL MEETING
September 6--10, 1988
Boston, Massachusetts
Room Reservation: Boston Park Plaza Hotel
One Park Plaza at Arlington
Boston, MA 02117 USA
Name (1)
No. in Party:
Name (2)
No. in Party:
Name (3)
No. in Party:
City
State
Country
Postal/Zip Code
Arrival Date
Time
Departure Date
Ref: Neural Networks
$91 (+ tax)/night, single or double
Reservations for arrival after 4PM must be guaranteed by:
( ) Check ($91 enclosed)
Or credit card:
( ) VISA
( ) American Express
Card No.:
Expiration Date:
Signature ______________________________________________________
If plans change or you need to cancel (before 4PM Boston time) call
(800) 225-2008 to avoid billing, and retain cancellation number given
by hotel agent.
Check in after 2PM-----Check out prior to 1PM.
MAIL TO: The Boston Park Plaza Hotel
Attn: Reservations Manager
50 Park Plaza
Boston, MA 02117 USA
(800) 225-2008 (Continental US)
(800) 462-2022 (Massachusetts only)
Telex 940107
****************************** cut here ******************************
---MEMBERSHIP APPLICATION FORM---
INTERNATIONAL NEURAL NETWORK SOCIETY
The International Neural Network Society(INNS) is an association of scientists,
engineers, students, and others seeking to learn about and advance our
understanding of the modelling of behavioral and brain processes, and the
application of neural modelling concepts to technological problems. The
INNS will sponsor its first annual international meeting in Boston,
Massachusetts, September 6-10, 1988. INNS membership includes a subscription
to Neural Networks, the official journal of the Society.
Membership Fees 1987--88 (including a 1-year subscription to Neural Networks)
( ) Regular $45
( ) Full-time Student $35
( ) Check or money order enclosed (payable to INNS).
Or Charge:
( ) American Express
( ) MasterCard
( ) VISA
( ) Diners Club
Account Number:
Expires:
Signature __________________________________________________
Name
Title
Department
Institution
Employment:
( ) University
( ) Government
( ) Industry
( ) Other
Mailing Address:
Electronic Mail Address:
Telephone(s):
Education:
Highest Degree
Date
University
Department
Check your principal areas of interest in neural networks:
( ) Vision and image processing
( ) Local circuit and systems analyses
( ) Speech and language understanding of brain-behavior relationships
( ) Pattern recognition
( ) Combinatorial optimization
( ) Associative learning and long-term memory
( ) Electronic hardware
( ) Self-organization
( ) Optical hardware
( ) Cognitive information processing
( ) Hybrid hardware
( ) Cooperative and competitive network dynamics in short-term memory
( ) Virtual devices
( ) Neurocomputers
( ) Sensory-motor control and robotics
( ) Parallel distributed processing
( ) Other
Signature ____________________________________________________
Date
Mail application to: Dr. Harold Szu
NRL, Code 5756
Washington, DC 20375-5000, USA
Telephone: (202) 767-1493
FAX: 202-767-4277
E-Mail: ARPNET--Szu @ NRL3
****************************** cut here ******************************
---CALL FOR PAPERS: NEURAL NETWORKS---
Neural Networks commences quarterly publication in January, 1988, of
articles about the full range of biological through technological
neural network models. Articles in the January issue will include:
Teuvo Kohonen, An introduction to neural computing.
Stephen Grossberg, Nonlinear neural networks: Principles, mechanisms,
and architectures.
Shun-ichi Amari, Statistical neurodynamics of associative memory.
Paul R. Gorman and Terrence J. Sejnowski, Analysis of hidden units in a
layered network trained to classify sonar targets.
Carver A. Mead and Misha Mahowald, A silicon model of early visual
processing.
Authors in the April, 1988, issue will include:
Kunihiko Fukushima
Robert Hecht-Nielsen
Christoph von der Malsburg
Demetri Psaltis
Allen Selverston
--Instructions for Authors--
Authors should submit four copies of each manuscript, plus original
illustrations. Do references in American Psychological Association format;
e.g., Hebb (1949). Submit from Asia and Australia to
Prof. Shun-ichi Amari
University of Tokyo
Faculty of Engineering
Instrumentation Physics Department
Bunkyo-ku, Tokyo 113
JAPAN
Submit from North and South America to
Prof. Stephen Grossberg
Center for Adaptive Systems
Boston University
111 Cummington Street
Boston, MA 02215 USA
Submit from Europe and Africa to
Prof. Teuvo Kohonen
Helsinki University of Technology
Technical Physics Department
Rakentajanaukio 2C
SF-02150 Espoo 15
FINLAND
-----
∂21-Nov-87 0127 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Supercomputing '88 Conference Announcement and Call for Papers
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 Nov 87 01:27:45 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Sat 21 Nov 87 01:21:45-PST
Received: by lindy.stanford.edu; Sat, 21 Nov 87 01:24:38 PST
Received: by Forsythe.Stanford.EDU; Sat, 21 Nov 87 01:25:01 PST
Received: by NDSUVM1 (Mailer X1.24) id 5678; Fri, 20 Nov 87 23:33:56 CST
Date: 21 Nov 1987 00:11:00-EST (Saturday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
George Adams <GBA%EE.ECN.PURDUE.EDU@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: George Adams <GBA%EE.ECN.PURDUE.EDU@forsythe.stanford.edu>
Subject: Supercomputing '88 Conference Announcement and Call for Papers
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
Supercomputing '88
November 14-18, 1988
Buena Vista Palace,
Lake Buena Vista, Florida, USA
Sponsored by:
Computer Society of the IEEE and ACM SIGARCH
In Cooperation with:
Argonne National Laboratory, Lawrence Livermore National Laboratory,
Los Alamos National Laboratory, NASA Ames Research Center,
National Center for Atmospheric Research,
National Science Foundation, SIAM, Supercomputing Research Center
Papers submitted by: March 14, 1988
Poster proposals due: August 2, 1988
Supercomputing '88 is a new conference that will bring together
supercomputing system researchers, designers, and users to
report new advances and experiences, state needs, suggest future
directions, and contribute to discussions. It will include
tutorials, a high quality technical program, on-line and video
taped demonstrations, informal poster sessions, vendor and
university exhibits, and product briefings.
TOPICS OF INTEREST. Examples include, but are not limited to,
the following:
Science and Supercomputing
The Impact of New Technology on the Future of Supercomputing
Supercomputing Execution Environment
Supercomputing Development Environment
Supercomputing Application Environment
Supercomputing System Evaluation
Supercomputing Management Issues
Mass Storage and Supercomputers
Technical Aspects of Products
User Experience
PAPERS. Authors are invited to submit papers which report
concrete results and experience. Papers reporting important
negative results are also encouraged. Selection criteria will
include originality, clarity, and relevance.
Requirements: Papers must be original material not previously
published. Papers must be submitted without conditions; authors
must obtain any necessary approvals and/or clearances prior to
submission. Copyright release will be required. Authors of
accepted papers will be responsible for retyping corrected
papers on special forms to be provided and for preparing visual
material for their presentations using guidelines to be
provided. Camera-ready copy is due July 18, 1988. Presentation
visual material is due for quality review October 4, 1988.
Instructions: Submit five copies to the Program Chairman by
March 14, 1988. Papers must be in English, be typed double-
spaced, and not exceed 25 pages (about 5000 words). Papers must
have: (1) a title page that lists the name, mailing and
electronic address, and telephone number for each author; (2) an
abstract; (3) keywords; (4) and the presentation media
requirement. For multiple author papers, identify the
corresponding author and the presenting author.
POSTERS. In addition to informal evening poster sessions, an
on-line poster session will be scheduled where people who have
developed interesting applications will demonstrate them using
exhibitor equipment.
Instructions: Contact the Program Chairman for all poster
proposals. Proposals for on-line posters should be made jointly
with the collaborating exhibitor.
SUPERCOMPUTING CENTER MANAGERS ROUNDTABLE. Special informal
sessions will be organized so that supercomputing center
managers can share recent progress, discuss common problems, and
consider opportunities for collaboration.
For information on the conference, program, or exhibits contact
one of the following:
General Chairman Program Chairman Exhibits Chairman
George Michael, L-306 Stephen F. Lundstrom Roger Anderson, L-306
LLNL ERL 455 LLNL
P. O. Box 808 Stanford University P. O. Box 808
Livermore, CA 94550 Stanford, CA 94305 Livermore, CA 94550
(415) 422-4239 (415) 723-0140 (415) 422-8572
gam@lll-crg.arpa lundstrom@sierra.stanford.edu anderson@lll-crg.arpa
For location and registration information contact the Computer
Society of the IEEE, 1730 Massachusetts Ave., N.W., Washington,
∂22-Nov-87 0134 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #89
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 22 Nov 87 01:34:24 PST
Date: Sat 21 Nov 1987 13:28-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #89
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Sunday, 22 Nov 1987 Volume 5 : Issue 89
Today's Topics:
Query - Proceedings & Test & Constraint LP,
Implementation - Prolog Machines & Type Conversion,
& Numbers & Specifications & Chestnuts
----------------------------------------------------------------------
Date: Tue, 17 Nov 87 22:10:49+0900
From: Dongwook Shin <dwshin%csd.kaist.ac.kr@RELAY.CS.NET>
Subject: Proceedings
Is there anyone out who has the ESPRIT'86 proceedings or knows
where to buy it? A report which appeared at ESPRIT Project 415
is important to me.
Thanks.
-- D.W. Shin
------------------------------
Date: 14 Nov 87 15:08:42 GMT
From: clyde!watmath!dalcs!aucs!ifocs9d@rutgers.edu (Rick Giles)
Subject: Tail Recursion Optimization Test
Is there a straightforward test one can apply to a Prolog implementation
which will indicate that it is very likely that the implementation applies
tail recursion optimization?
------------------------------
Date: Mon, 9 Nov 87 11:26:08 GMT
From: Fernando Pereira <pereira%cam.sri.com@drakes.ai.sri.com>
Subject: Chat LIPS
Being the author of the natural-language analysis part of the Chat-80
program that Mike Carlton mentions in his message about Prolog
machines, I'm baffled at his statement that the new VLSI PLM achieves
``98 KLIPS for Warren's [sic] Chat program''. How is this measured?
The system contains a top-level loop with reader, a parser, two
semantic interpretation modules, a simplifier, a query planner, a
query evaluator and a database, all with very different coding styles,
different uses of evaluable predicates, and with different degrees of
determinacy. For most examples, execution time for a query is
dominated by database access, which includes calls to ``setof''. How
could one draw any useful conclusion from a single aggregate number
for the whole program? How does one measure ``LIPS'' for programs
using ``setof''?
------------------------------
Date: 9 Nov 87 21:52:17 GMT
From: tektronix!sequent!mntgfx!bobk@ucbvax.Berkeley.EDU (Bob Kelley)
Subject: Constraint Logic Programming info sought
I haven't heard much in this Digest about Constraint Logic Programming.
It seems to me that CLP is what I originally thought PROLOG should have
been, before I learned about PROLOG.
Can anyone describe exactly what the differences are between CLP and PROLOG?
Is it practical to modify existing PROLOG interpreters to handle, say,
CLP(R)? Is it practical to do this with compiled PROLOG systems based on
the Warren Abstract Machine, e.g. SB-Prolog?
I have heard that some CLP systems involve some sort of constraint solver
grafted on to a regular PROLOG system. What tasks would such a solver
be able to perform in the domain of real numbers? Would it solve sets
of simultaneous equations and inequalities? Would it need to do any
algebraic rearrangement of clauses? Could a CLP(R) meta-interpreter be
written in PROLOG?
-- Robert J. Kelley
------------------------------
Date: 17 Nov 87 02:43:14 GMT
From: ji.Berkeley.EDU!holmer@ucbvax.Berkeley.EDU (Bruce K. Holmer)
Subject: Integer/floating point type conversion in Prolog
[]
In your opinion, what is the proper behavior of the following code fragments?
% Is type conversion is done before test?
main1 :- a(1.0, 1).
a(X, Y) :- X == Y, write(a), fail.
a(X, Y) :- X = Y, write(b), fail.
a(X, Y) :- X =:= Y, write(c), fail.
% What about round-off errors?
main2 :- X is (2.0/7.0)*7.0, Z is X - 2.0, write(Z), b(X, 2.0).
b(X, Y) :- X == Y, write(a), fail.
b(X, Y) :- X = Y, write(b), fail.
b(X, Y) :- X =:= Y, write(c), fail.
To save you the work, here are the results for prologs we use:
C-Prolog (version 1.5)
main1: abc
main2: 0abc
Quintus (VAX version 1.6 interpreted):
main1: c
main2: -1.9073e-06
Quintus (VAX version 1.6 compiled):
main1: c
main2: 0.0abc
SB-Prolog (version 2.2 compiled)
main1: bc
main2: -0.000000b
As you can see, no one can agree on what the correct answers are!
So should type conversion be done before =/2 or ==/2?
Quintus says no, C-Prolog says yes, and SB-Prolog is in between.
Concerning round-off errors, Quintus compiled code probably computes
multi-operation expressions with full precision (and rounds the
answer), whereas execution time floating point is 29-bit for all
operations. My opinion is that a program should produce identical
results, regardless of whether it is interpreted or compiled.
SB-Prolog uses an 'EPSILON' during unification to do a
'prettymuch_equal', but I would think that anything that is '=/2'
should also be '=:=/2'.
Thanks for your comments,
-- Bruce
------------------------------
Date: 17 Nov 87 19:15:59 GMT
From: cbosgd!mandrill!leon@ucbvax.Berkeley.EDU (Leon Sterling)
Subject: Comparing numbers
Bruce Holmes questions' are good examples of `kosher pigs',
i.e. strictly legalistic curiosities that can't (more realistically
shouldn't) arise.
In his example of type conversion, only one of the queries makes
sense, namely 1.0 =:= 1? (The testing procedure is irrelevant.)
This is the ONLY Prolog predicate which does evaluation as part of its
comparison.
It is probably sensible for this goal to succeed, thouigh it would
not be unreasonable for =:= only to compare values of the same type.
The meta-logical test 1.0 == 1? should only be applied to non-ground
terms. If its behaviour must be defined, I feel strongly that the
query should fail. The real number 1.0 is not the same object as the
integer 1.
The unification test 1.0 = 1? should also fail, it seems to me.
Do we want a list with one element, a say, to unify with a binary
tree with a single leaf node a?
Roundoff behaviour is a question for implementing arithmetic,
and is irrelevant in language design.
-- Leon Sterling
------------------------------
Date: Fri, 20 Nov 87 19:51:27 EST
From: munnari!mulga.oz.au!lee@uunet.UU.NET (Lee Naish)
Subject: Specifications vs programs
Fernando suggested the following specification for append:
(forall x y z) (list(x) & list(y) & append(x,y,z) =>
list(z) & x::y = z)
where :: is the list concatenation function.
A problem with it is that the following query may result in X and/or Y
being bound to arbitrary non-lists:
?- append(X, Y, [1,2,3]). % eg. X=42, Y=g(fred)
It is important for Prolog procedures to be complete (at least when they
terminate normally, ie. fail on backtracking eventually), as well as sound.
Recently I wrote some code in the following form:
all ... (append(...), ... => ...)
Implication (in NU-Prolog) is implemented using not, which uses negation
as failure. NAF is unsound if procedures terminate without returning
all true answers. The code above will return an incorrect answer with
the following (sound by not complete wrt the intuitive specification)
definition of append:
append(_, _, _) :- fail.
The high level specification for which (standard) append/3 is sound and
complete is horrible. The sound and complete implementation of the
intuitive specification is also not good (its inefficient).
I think my approach using types is a reasonable solution to this
dilemma, though it would be nicer for everyone if the dilemm didn't
exist in the first place.
P.S. please dont leave this message around where anti-Prolog people may
see it :-).
------------------------------
Date: Sun, 15 Nov 87 01:02:10 PST
From: quintus!ok@Sun.COM (Richard A. O'Keefe)
Subject: An Old Chestnut
I see that an old chestnut is being discussed again.
The problem is that
ancestor_descendant(Anc, Des) :- /* V1 */
parent_child(Anc, Des).
ancestor_descendant(Anc, Des) :-
parent_child(Anc, Cld),
ancestor_descendant(Cld, Des).
looks good for finding descendants of a known ancestor,
but searches blindly for ancestors of a known descendant.
The question is what should be done to this to make it
beahve itself both ways around.
Jeff Schultz suggests either coding both directions of the
relation and picking the appropriate one depending on the
instantiation state of the arguments (this is what used to
be done in IC-Prolog: you could write several copies of a
clause that differed only in goal order; IC Prolog realised
that they were really the same clause and would pick one)
or else using some form of delaying.
Micha Meier also suggests using some sort of delaying.
There are several important points. One is that delaying is
not really going to help. What delaying will do for you is
to put off anything that looks too hard. Eventually SOMEONE
has to guess a descendant otherwise the ancestor_descendant
goal will NEVER be executed. As Jeff Schultz's program shows,
delaying is a good way to do the scheduling, but you still
have to code both directions of the relation.
But there is more to worry about. The ancestor_descendant
code given above only LOOKS ok for finding descendants of a
known ancestor. In fact, unless the parent/child graph is
a tree, that code is SHOCKINGLY inefficient.
What do I mean? Well, let's confine ourselves to parent/child
graphs which are acyclic, but relate N individuals.
ancestor_descendant(A, D) may prove the relatedness of
*given* A and D O(2**N) times. Consider the graph
for i = 1..N/2 {
parent(a[2i+0], a[2i+2]).
parent(a[2i+1], a[2i+2]).
parent(a[2i+0], a[2i+3]).
parent(a[2i+1], a[2i+3]).
}
(i.e. N/2 generations of brother-sister incest.)
It is also easy to construct an acyclic graph in which there
is a unique path from A to D, but an exponential amount of
work is done searching for it.
So even in the "forward" direction (whichever that is, both these
nasties happen when both A and D are known) this algorithm is
pretty blind.
The nice thing about declarative programming is that you can write
a specification and run it as a program. The nasty thing about
declarative programming is that some clear specifications make
incredibly bad programs. The hope of declarative programming is
that you can move from a specification to a reasonable program
without leaving the language.
What is the best way to handle transitive closure problems like this?
Well, a logic programming system with a bottom-up component should be
able to do a reasonable job by computing the closure bottom-up. For
ordinary Prolog systems, it is possible to compute the transitive
closure of a graph expressed as a list of From-To arcs in cubic time.
{See the predicate warshall/2 in the DEC-10 Prolog library file
GRAPHS.PL or the Quintus Prolog library file library(graphs).}
Even doing
ancestor_descendant(Ancestor, Descendant) :- /* V2 */
setof(Parent-Children,
setof(Child, parent_child(Parent, Child), Children),
Graph),
warshall(Graph, Closure),
member(Ancestor-Descendants, Closure),
member(Descendant, Descendants).
(which doesn't look too good) has cubic cost, which beats exponential
any day. {By the way, this is yet another of the many examples where
it is a major help that setof/3 never yields an empty answer.}
Yes, the calls to setof/3 are going to take O(N**2.lg(N)) time here,
but this is dominated by the O(N**3) time of warshall/2.
A practical compromise might be to cache this result:
:- dynamic
parent_child/2,
anc_des/2,
needs_recomputing/0.
c_assert(Fact) :-
( clause(Fact, true) -> true
; assert(Fact)
).
add_link(P, C) :-
( parent_child(P, C) -> true
; assert(parent_child(P, C)),
c_assert(needs_recomputing)
).
del_link(P, C) :-
( retract(parent_child(P, C)) ->
c_assert(needs_recomputing)
; true
).
recompute_if_necessary :-
( retract(needs_recomputing),
retractall(anc_des(_, _)),
setof(Parent-Children,
setof(Child, parent_child(Parent, Child), Children),
Graph),
warshall(Graph, Closure),
member(Ancestor-Descendants, Closure),
member(Descendant, Descendants),
assert(anc_des(Ancestor, Descendant)),
fail
; true
).
ancestor_descendant(Ancestor, Descendant) :- /* V3 */
recompute_if_necessary,
anc_des(Ancestor, Descendant).
Now, while the parent/child graph isn't changing, a call to
ancestor_descendant/2 takes at worst quadratic time, and when
the graph does change, it takes cubic time to recompute it.
As a matter of fact, I had a paper in the Melbourne conference
which showed how the transitive closure could be maintained as
linked were added and still maintain cubic total time. I have
no idea how to attain this upper bound if links are deleted.
Of course the program V2 is not as pretty as the specification V1,
but it is enormously more efficient in the general case (it has no
trouble with cyclic graphs, for example) and it is still declarative.
With release 2.0 of Quintus Prolog and the latest versions of
library(graphs) and library(ordsets) -- that's the one that speeded
up by 20% when I made it purer -- the cross-over for V2 being faster
than V1 on an incestuous graph is N=10. For N=20, V2 was 10 times
faster than V1, and V3 was another 12 times faster still.
For a 120-fold speed-up, I'm prepared to put up with a lot...
I tried V1, V2, and V3 on some randomly generated acyclic graphs
with N=20 nodes. The lowest V1/V2 ratio I obtained was 6 (that is
the setof & warshall version was six times faster), and V3 was some
70 times faster still. That's a V3/V1 speedup of 420 for a tiny
little graph. I'm not sure that my definition of "random" graphs
is reasonable, so this should still be taken as upper bound-ish.
I have a nasty feeling that there is an O(N**2) algorithm for finding
the transitive closure of an acyclic graph and that I'm looking silly
using a cubic algorithm. Anyone know if there is, and if so what?
So, if you want to find transitive closures, a little bit of patching
here and there with :-when declarations simply isn't good enough.
You have to use a better algorithm, and if you do that, the original
problem happens to go away.
------------------------------
End of PROLOG Digest
********************
∂23-Nov-87 0112 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #90
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Nov 87 01:09:33 PST
Date: Sat 21 Nov 1987 14:47-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #90
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Monday, 23 Nov 1987 Volume 5 : Issue 90
Today's Topics:
Query - Segmentation & Bug & Syntax,
Implementation - Badness,
Announcement - Benchmarking Workshop
----------------------------------------------------------------------
Date: 18 Nov 87 14:44:41 GMT
From: trwrb!aero!gillam@ucbvax.Berkeley.EDU (April Gillam)
Subject: Segmenting a Prolog Data Base to Speed Up Search
We are developing a quasi expert system to make a conceptual design
of a spacecraft. This involves a lot of data and rules at the
spacecraft mission level and at the subsystem(acs,power,comm,etc.)
level. We will also be keeping track of 'historical' info on spacecraft
that have already been launched.
The system is being written in Quintus Prolog, which is relatively new to
me. Is there some way to segment the data bases so that there are fewer
facts for the 'matcher' to plough through till it finds the appropriate
data? I have been considering separating the data into different files
and only loading in what is needed to do the inferencing & calculations,
& then deleting it -- if I can figure out when to do that & hope the
overhead is less than the search time when all that info is in the
database at once.
I've implemented Sterling & Shapiro's symbolic equation solver with some
enhancements, but it is fairly slow on the substitution part. (By the way,
I recommend The Art of Prolog. It's been very useful.) I'm assuming that
is because there's so much data associated with each spacecraft, and for
simplicities sake I'm using the same format for most of the data. This
allows many routines to be used in many different situations, but there is
all that data!
Thanks for any help on this.
-- April Gillam
------------------------------
Date: 19 Nov 87 21:16:00 GMT
From: finin@bigburd.prc.unisys.com (Tim Finin)
Subject: bug or feature?
Is it a bug or a feature for a logic programming language to allow one
to assert multiple copies of a clause into the database?
I'm studying various ways to extend Prolog's simple model of the
database (e.g. a flat, global collections of clauses) to a richer
hierarchical one with inheritance. I am trying to decide whether to
allow multiple instances of a clause in a resulting database view.
Most Prolog implementations, at least those descendant from DEC-10
Prolog, allow the database to contain two identical clauses. Most of
the non-Prolog logic programming languages that I am familiar with do
not. I am interested in discovering what use, if any, people have
made of the ability to assert multiple copies of a clause into the
database.
I have never found a use for this in practice. In fact, it has only
been a source of bugs. It is easy enough to accidentally get multiple
copies of a clause in the database in some Prolog implementations.
This can readily mess up your program in several ways unless you use a
rather pure logic programming style.
Has anyone out there found a good use for this Prolog "feature" of
allowing multiple copies of the identical clause in the database?
-- Tim
------------------------------
Date: 18 Nov 87 21:09:31 GMT
From: ncc!ers!alberta!abdul@speedy.wisc.edu (Abdul Sattar)
Subject: Question about Prolog-10 syntax
Following clause appears on page number 208 of ALGORITHMIC PROGRAM DEBUGGING
by Ehud Y. Shapiro:
forall(X,P,Y) <-
setof(Y,X↑P,S), forall1(S).
Note: the symbol ↑ is an arrow pointing upwards.
Will somone explain me the meaning of this symbol?
-- Abdul
------------------------------
Date: Thu, 19 Nov 87 11:19:52 +1100
From: munnari!mulga.oz.au!lee@uunet.UU.NET
Subject: Badness
I discuss the "incorrectness" of append in "Specification = Program +
Types", procceedings of FST&TCS, Dec 1987.
I argue that in the *natural* specification for append, all arguments
must be lists. The paper introduces the notion of "type correct"
programs (which can include the normal version of append) and shows
why these programs do not produce incorrect well typed answers. The
Mycroft/O'Keefe type checker can also be used to catch programs which
call append with non-lists.
-- Lee Naish
------------------------------
Date: Fri, 20 Nov 87 15:20:20 cst
From: stevens@anl-mcs.ARPA (Rick L. Stevens)
Subject: Prolog Benchmarking Workshop
During the last SLP there was some concern that the benchmark programs
being quoted in the literature did not reflect real Prolog programming
practices. Now is your chance to do something about it. A workshop
on benchmarking Prolog programs will be held at The Aerospace
Corporation in Los Angeles. The main function of this workshop is to
collect and measure a large number of modern production (real
application) Prolog programs.
The workshop will last three days, and will be held sometime during
the first two weeks of February. The exact date will be selected to
enable the most people to attend. The workshop will be sponsored by
The Aerospace Corporation and is being held under the auspices of the
Association of Logic Programming. Since resources for running the
benchmarks will be limited the meeting will be open only to those who
contact the organizers.
The first half of the workshop will be spent discussing the performance
issues we wish to address, porting of code, and instrumenting of
Prolog programs and implementations. The second half will be spent
running the code and collecting and analyzing the data.
We hope to publish the results either as a widely available Technical
Report or as a special journal article in a journal such as the Journal
of Logic Programming or New Generation Computing.
Attendance at the workshop will be limited to those who either bring
an implementation of Prolog or 1,000 or more lines of "original"
Prolog source. Programs with more than 1,000 lines will certainly be
accepted. The thing we wish to guard against is toy programs that
don't reflect the serious use of the language.
Of course, we would like code that has been written recently and that
reflects the best of Prolog style. But any ``real'' Prolog application
would be acceptable. ( No code with more that 3 cuts per clause.
:-)). Hopefully those in attendance will represent a balance between
University and Commercial applications.
The code brought should be covered by a GNU type ``copyleft''. That
is unlimited distribution of unmodified sources. The object is to get
unmodified copys of programs and input data sets to as many people as
possible. The Aerospace Corporation, a non-profit organization will
distribute the benchmark suite.
We would like to have the environment set up in advance so as much time
as possible can be spent on performance analysis. To do this
we will set up a mail address where code can be e-mailed in advance.
Participants can also bring a UNIX tar tape. The computers available at
Aerospace include a Sequent, VAXes, Suns, and various types of
PCs. We will try to have as many different implementations of Prolog
available as possible.
A limited amount of financial support from the Aerospace Corporation
will be available for University attendees.
Please let us know by December 15, 1987 if you intend to attend.
If you want to attend, please send us your
name,
e-mail address,
country of citizenship,
smail address,
date, if you have a preference
if you will need financial support
date that would be best for you, and
what you'll bring.
Send responses to:
prolog-workshop@anl-mcs.arpa
If you can't get ahold of us through e-mail, you can use:
Carl Kesselman Rick Stevens
MS M1/102 Math and Computer Science Division
The Aerospace Corporation Argonne National Laboratory
P.O. Box 92957 Argonne IL 60439
Los Angeles, CA 90009-9295 (312) 972-3378
(213) 336-6691
If you have a problem with the distribution agreement, questions or
suggestions, please contact us at the above address.
Hope to see you there.
Rick Stevens Carl Kesselman
stevens@anl-mcs.arpa carl@aerospace.aero.org
Argonne National Laboratory The Aerospace Corporation
------------------------------
End of PROLOG Digest
********************
∂23-Nov-87 0908 RICHARDSON@Score.Stanford.EDU Faculty Lunch
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Nov 87 09:08:02 PST
Date: Mon 23 Nov 87 09:02:02-PST
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: Faculty Lunch
To: faculty@Score.Stanford.EDU
Message-ID: <12352935624.14.RICHARDSON@Score.Stanford.EDU>
There will be general discussion at the faculty lunch on Tuesday, November 24
at 12:15 in MJH 146. In addition, we will have the following guests from DEC:
Ms. Teresa Clock, Mr. Larry Goodwin, and Ms. Susan Stevenson who will be
presenting Anoop Gupta with a certificate from DEC. He has been selected
to participate for a second year in the Digital Faculty Program: Incentives
for Excellence. Join us in congratulating him!
-------
∂23-Nov-87 1120 OKUNO@SUMEX-AIM.STANFORD.EDU Dr. Sridharan's report
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Nov 87 11:19:28 PST
Date: Mon, 23 Nov 87 11:18:25 PST
From: Hiroshi "Gitchang" Okuno <Okuno@SUMEX-AIM.STANFORD.EDU>
Subject: Dr. Sridharan's report
To: aap@SUMEX-AIM.STANFORD.EDU
Organization: Knowledge Systems Laboratory, CSD, Stanford University
Group: Heuristic Programming Project
Project: Advanced Architectures Project
Address: 701 Welch Road, Building C, Palo Alto, CA 94304-1703
Phone: +1 (415)725-4854
Message-ID: <12352960452.42.OKUNO@SUMEX-AIM.STANFORD.EDU>
I got a copy of the following report from Dr. Sridharan who had gave a
talk about "Meeting Real-time Requirements in AI Systems" at SIGLUNCH.
Final report for Real-Time Cooperative Expert Systems Evaluation.
by Dr. Sridharan et al, FMC, Sept. 1987.
If you are interested in the report, please drop by at my office.
- Gitchang -
-------
∂23-Nov-87 1430 TOM@Score.Stanford.EDU Locking of computer room(020)
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Nov 87 14:30:16 PST
Date: Mon 23 Nov 87 14:23:31-PST
From: Thomas Dienstbier <TOM@Score.Stanford.EDU>
Subject: Locking of computer room(020)
To: csd@Score.Stanford.EDU, staff@Score.Stanford.EDU,
faculty@Score.Stanford.EDU
Message-ID: <12352994147.13.TOM@Score.Stanford.EDU>
Due to the increase of thefts at the University, it has been decided to lock
the computer room doors(room 020) over the holidays(Thanksgiving, Xmas and
NewYears).
Times and dates as follows:
Thanksgiving; Doors locked from November 25, 1500 thru November 30, 0700 hours.
Christmas; Doors locked from December 23, 1500 thru December 28, 0700 hours.
New Years; Doors locked from December 31, 1500 thru January 4, 0700 hours.
Keys that will open the doors are building master, building grand master,
and facilities master. If you feel that you need access to this area
during the times listed and don't have the appropriate key, please contact me.
tom
-------
∂23-Nov-87 1658 OKUNO@SUMEX-AIM.STANFORD.EDU my absence in December
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Nov 87 16:58:51 PST
Date: Mon, 23 Nov 87 16:49:10 PST
From: Hiroshi "Gitchang" Okuno <Okuno@SUMEX-AIM.STANFORD.EDU>
Subject: my absence in December
To: aap@SUMEX-AIM.STANFORD.EDU
cc: communications@SUMEX-AIM.STANFORD.EDU
Organization: Knowledge Systems Laboratory, CSD, Stanford University
Group: Heuristic Programming Project
Project: Advanced Architectures Project
Address: 701 Welch Road, Building C, Palo Alto, CA 94304-1703
Phone: +1 (415)725-4854
Message-ID: <12353020663.42.OKUNO@SUMEX-AIM.STANFORD.EDU>
I'll be out of town from December 1st to 16th to attend a conference
(MICRO-20) in Colorado Springs and then back to Japan.
Please feel free to use my Explorer (X10) and terminal (VT100
compatible). If you want to use them and the door is locked,
ask Nancy or Flora to unlock it.
- Gitchang -
-------
∂24-Nov-87 0149 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #91
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Nov 87 01:49:28 PST
Date: Mon 23 Nov 1987 09:02-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #91
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Tuesday, 24 Nov 1987 Volume 5 : Issue 91
Today's Topics:
Query - WAM,
Theory - Impediments,
Implementation - Algorithmic Debugging
----------------------------------------------------------------------
Date: Fri, 20 Nov 87 09:54:23+0900
From: Dongwook Shin <dwshin%csd.kaist.ac.kr@RELAY.CS.NET>
Subject: Compiling Prolog features
I'd like to know how to compile two Prolog features on the Warren
Abstract Machine. First is how to compile high-order feature, say,
call. As the argument of "call" is made in run-time, it seems that
the execution of the argument is different from the normal execution.
Second is how to embed the information on the operator precedence from
"op(_,_,_)" into WAM. Any information would be appreciated.
-- D.W. Shin
------------------------------
Date: Sun, 22 Nov 87 15:40:37 PST
From: narain%pluto@rand-unix.ARPA
Subject: Theoretical impediments to logic programming?
In his paper "Theoretical impediments to Artificial Intelligence" M.
Rabin points out that deciding truth of even the simplest of sentences in
logic can require super-exponential time.
Specifically, he cites a theorem obtained by him and M.J. Fischer. Let L
be the set of all sentences of first order logic written using +, =, ~,
->, (). Let <N,+> be the structure consisting of the set N={0,1,2,..} of
natural numbers with the operation + of addition. Then Presburger
Arithmetic (PA) is said to be the set of all sentences in L which are true
in <N,+>. PA is decidable. The theorem states that:
There exists a constant c>0 such that for every decision
procedure (algorithm) AL for PA, there exists an integer
n0 so that for every n>n0 there exists a sentence F of L
of length n for which AL requires more than 2**(2**(c*n))
computational steps to decide whether F is in PA.
Surely the Horn clausal calculus is richer than L, so this complexity
result should apply to SLD-resolution. Does this diminish its importance?
To answer this question, let us address a related one: what is the
advantage of SLD-resolution over conventional brands of resolution, say,
hyper-resolution? One might rather hastily answer that the former is
"more efficient" than the latter. Presumably this would mean that for
every refutable set of Horn clauses, the number of steps required by
SLD-resolution to refute it is less than or equal to that required by
hyper-resolution. To see that this is, in general, false, consider the
following set of clauses:
<-fib(s(s(s(s(0)))),Z).
fib(0,s(0)).
fib(s(0),s(0)).
fib(s(s(X)),Z)<-fib(s(X),Z1),fib(X,Z2),plus(Z1,Z2,Z).
plus(0,X,X).
plus(s(X),Y,s(Z))<-plus(X,Y,Z).
The number of steps required by SLD-resolution to refute it is larger than
that required by hyper-resolution.
So, the importance of SLD-resolution cannot be that it is "more efficient"
than other proof procedures. Instead it appears to lie in its simplicity
and consequent programmability. It is simple enough that one can
visualize and predict its behavior as it is interpreting Horn clauses.
This enables one to write clauses in such a way that when SLD-resolution
interprets them it behaves, in most cases, in whatever fashion one wishes
it to behave. In particular, one can use clauses not only to express
relations but also to express *algorithms* for computing them.
For example, not only can one write clauses expressing the list reversal
relation, one can do so in such a way that lists are reversed in a number
of steps proportional to their length. Not only can one write clauses
expressing the sorting relation, one can do so in such a way that lists
are sorted in a number of steps proportional to that required by quicksort
(or mergesort, or bubblesort). Not only can one write clauses expressing
grammar rules, one can do so in such a way that phrases are parsed in a
top-down fashion.
In contrast, resolution does not enjoy this property of programmability.
Its behavior is substantially more difficult to visualize and predict, and
hence to control.
Once algorthims are expressed as clauses they can be analyzed as
statements of logic with all attendant benefits. Thus the central
importance of SLD-resolution is that it allows expression of *algorithms*
in a logical framework. This point, of course, was made originally by
Kowalski when he introduced the procedural interpretation of Horn clauses.
It is still the programmer's responsibility to develop good algorithms.
SLD-resolution only behaves as efficiently as the algorithms which it is
interpreting will permit it to behave. It does not claim to be an optimal
proof procedure. Hence the result of Rabin and Fischer does not diminish
its importance.
Comments?
-- Sanjai Narain
------------------------------
Date: Thu, 19 Nov 87 22:29:29+0900
From: Dongwook Shin <dwshin%csd.kaist.ac.kr@RELAY.CS.NET>
Subject: A comment on Algorithmic Debugging
Recently, we are developing a practical version of Algorithmic
debugger originally devised by Shapiro. One of the most confus-
ing problem in Shapiro's algorithm is occurred when the solution
set in a user's mind is actually different from that in declara-
tive semantics and the user hardly understand the error checking
message. Let me take a simple example.
(1) g(X,Y) :- even(X), Y is X/2.
(2) g(X,X).
(3) even(X) :- 0 is X mod 3
In this example, the error a user may explicitly recognize is in
clause (3). In other words, the user may take the clause (2) for
being correct, because he may think clause (2) is executed only
when clause (1) fails, i.e., he think clause (2) is equal to
"g(X,X) :- not(even(X)).". However, we might not blame him, as
the very one to be blamed is the non-fair search mechanism in
Prolog and he is only a victim of this mechanism.
Consider the Shapiro's algorithmic debugger in more detail.
Let's suppose that a user drops a query "q(4,X)". He certainly
gets the wrong answer "g(4,4)" with the above program and he
thinks it is wrong because he expects X would be instantiated to
2. Now, suppose he decides to run the wrong solution mode. In
this mode, he may respond with "no" to the question "g(4,4) is
correct?", so force the debugger to decide that the wrong clause
is (2), because g(4,4) logically follows from g(X,X). However the
user may be confused with this decision if he is not well trained
in Logic. Can you tell he does not have the quality enough to use
such a beautiful "Logic"? If you can, I'll give you the following
program.
(1) g(X,Y) :- even(X), Y is X/2.
(2) g(X,X).
(3) even(X) :- 0 is X mod 2.
You will think this is wrong. However almost all Prolog systems
do not tell that the clause (2) is wrong. Isn't it strange that
when "0 is X mod 2" is changed to "0 is X mod 3", the debugger
tells that "g(X,X)" is not correct, which was not told in the
original program?
As mentioned above, I'd like to say again that the basic reason
why users tend to write codes like that is in the sequentiality
of Prolog. Therefore, the debugger should consider this situa-
tion. Finally, I'd like to draw the following conclusion:
If the Prolog execution mechanism is sequential, i.e., non-fair
in its search mechanism, the debugger should provide the flexi-
bility for victims of this non-logical feature. So, We suggest
the following policy in the algorithmic debugging.
In the first program, if a user answers "no" to the question
"q(4,4) is true?" thrown by the debugger, the debugger should
confirm the user's opinion like this: "Do you think the clause
g(X,X) is false?". If the user is well trained in logic and not
contaminated by the Prolog's sequentiality, he will surely recog-
nize that the clause g(X,X) is not true and answer "yes". So the
debugger can conclude that g(X,X) is false. Now if he replaces
"g(X,X)" by "g(X,X) :- not(even(X))", this time, the debugger
will indicate that even(X) is not correct, finally compel him to
make a complete program. Shapiro's algorithmic debugger assumes
only such a "high-level" programmer and "high-level" process of
debugging (poor people may complain this process is user-
unfriendly).
However, if a user is not well trained in logic, or contaminated
by the Prolog's sequentiality, he may think the clause "g(X,X)"
is not false, so definitely respond with "no" to the question "Do
you think the clause g(X,X) is false?". The debugger should be
able to find that the wrong clause he wants is "even(X) :- 0 is X
mod 3", not "g(X,X)".
We are developing an algorithmic debugger with the above policy.
Do you have any comment on this policy? Will Lee Naish also at-
tack this policy with his electronic butcher's knife? Will
O'keefe say that the policy will only accelerate Lisp-like pro-
gramming in Prolog?
-- D.W. Shin
------------------------------
End of PROLOG Digest
********************
∂24-Nov-87 0842 TAJNAI@Score.Stanford.EDU NilsNews to Alumni and Friends
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Nov 87 08:42:44 PST
Date: Tue 24 Nov 87 08:36:40-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: NilsNews to Alumni and Friends
To: faculty@Score.Stanford.EDU, sec@Score.Stanford.EDU
Message-ID: <12353193151.16.TAJNAI@Score.Stanford.EDU>
If you or your students have received honors, awards, prizes, etc.
send the information to me and I'll include it in NilsNews which
is to go out next week.
The new CSD brochure should be completed next week and we'll mail
the newsletter with the brochure to alumni and friends of the department.
Carolyn
-------
∂24-Nov-87 1024 GILBERTSON@Score.Stanford.EDU Wednesday at 3
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Nov 87 10:24:10 PST
Date: Tue 24 Nov 87 10:14:26-PST
From: Edith Gilbertson <GILBERTSON@Score.Stanford.EDU>
Subject: Wednesday at 3
To: csd-list@Score.Stanford.EDU
cc: gilbertson@Score.Stanford.EDU
Message-ID: <12353210947.19.GILBERTSON@Score.Stanford.EDU>
23-Nov-87 11:15:50-PST,541;000000000001
Mail-From: GILBERTSON created at 23-Nov-87 11:15:48
Date: Mon 23 Nov 87 11:15:47-PST
From: Edith Gilbertson <GILBERTSON@Score.Stanford.EDU>
Subject: Wednesday at 3
To: CSD@Score.Stanford.EDU
cc: Gilbertson@Score.Stanford.EDU
Message-ID: <12352959973.27.GILBERTSON@Score.Stanford.EDU>
Computer Science Gang,
The CSD will close at 3 on Wednesday afternoon, November 25 -- a decision
of our gracious chairman.
Thanks, Nils, for the extra turkey time!
and
Happy Thanksgiving -- everyone!!
-Edie Gilbertson
-------
-------
∂24-Nov-87 1404 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talks
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Nov 87 14:04:45 PST
Date: Tue 24 Nov 87 13:56:57-PST
From: Anil R. Gangolli <GANGOLLI@Sushi.Stanford.EDU>
Subject: Upcoming AFLB Talks
To: aflb.all@Sushi.Stanford.EDU
Office Phone: (415) 723-3605
Message-ID: <12353251456.14.GANGOLLI@Sushi.Stanford.EDU>
PLEASE NOTE THE FOLLOWING:
* This week there is no AFLB talk.
NEXT WEEK'S TALK:
3-December-87: Noam Nisan (UC Berkeley)
Probabilistic vs. Deterministic Decision Trees
and CREW PRAM complexity
In the boolean decision tree model the only cost associated with an
algorithm is the number of input bits examined. We compare the
deterministic versus probabilistic complexities of boolean functions
in this model, both for 1-sided error probabilistic computation and
for 2-sided error computation. In both cases we show a polynomial
relationship.
Our techniques involve the new notion of the "block sensitivity" of a
function, a generalization of the critical sensitivity measure. They
apply to a completely different model of computation as well: the CREW
PRAM. We show that the block sensitivity completely characterizes the
complexity in the CREW PRAM model (with an unbounded number of
processors). We get that the parallel time it takes to compute f on a
CREW PRAM with an unlimited number of processors is equal (up to a
constant factor) to the logarithm of the boolean decision tree
complexity of f.
*** Time and Place: 12:30pm, Thurs., Dec. 3 MJH (Bldg 460), Room 352 ***
-------
∂24-Nov-87 1603 @SUMEX-AIM.STANFORD.EDU:HAILPERIN@Sushi.Stanford.EDU vineet singhs oral
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Nov 87 16:03:04 PST
Received: from Sushi.Stanford.EDU by SUMEX-AIM.STANFORD.EDU with TCP; Tue, 24 Nov 87 16:01:54 PST
Date: Tue 24 Nov 87 15:56:22-PST
From: Max Hailperin <HAILPERIN@Sushi.Stanford.EDU>
Subject: vineet singhs oral
To: aap@SUMEX-AIM.Stanford.EDU
Message-ID: <12353273194.47.HAILPERIN@Sushi.Stanford.EDU>
Did anyone go to Vineet's oral? I'd have liked to but was previously
comitted; I'd much appreciate a summary from anyone who went.
-------
∂25-Nov-87 1157 ullman@navajo.stanford.edu papers received
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 25 Nov 87 11:57:45 PST
Received: by navajo.stanford.edu; Wed, 25 Nov 87 11:48:56 PST
Date: Wed, 25 Nov 87 11:48:56 PST
From: Jeff Ullman <ullman@navajo.stanford.edu>
Subject: papers received
To: nail@navajo.stanford.edu
I've accumulated a number of papers that the community ought to
know about.
"Management of Stratified databases,"
K Apt and J-M. Pugin, TR-87-41 U. Texas
They discuss maintaining the "perfect model" of a stratified DB
in instantiated form, while updates are made to the EDB.
"The expressive power of stratified logic programs,"
P. Kolaitis, Stanford CSD.
Shows that (for finite structures) the fixed point operator is more
powerful than stratified logic.
2 papers by M. Kifer and E. Lozinskii, available from Kifer at SUNY Stony Brook.
"On compile-time query optimization in deductive databases by means of
static filtering"
Discusses algebraic optimizations for logic programs.
"SYGRAF": implementing logic programs in a database style"
Discusses bottom-up evaluation of logic.
3 papers by Serge Abiteboul (INRIA) and Victor Vianu (UCSD):
"Procedural and declarative database update languages"
"A transaction-based approach to relational DB specification"
"Transaction languages for DB update and specification"
In each case, the title is self-explanatory.
"The powerset as an algebraic tool for understanding least fixed point
semantics in the context of nested relations,"
M. Gyssens and D. Van Gucht, TR 233, Indiana Univ.
Again, the title covers it.
Also, I have received a number of extended abstracts that were
(I assume) sent to PODS. If the authors are willing to
mail out copies to interested people, I suggest they
announce that by mailing to nail@navajo.stanford.edu
---jeff
∂25-Nov-87 1201 TOM@Score.Stanford.EDU csd security
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 25 Nov 87 12:00:58 PST
Date: Wed 25 Nov 87 11:54:05-PST
From: Thomas Dienstbier <TOM@Score.Stanford.EDU>
Subject: csd security
To: csd@Score.Stanford.EDU, staff@Score.Stanford.EDU,
faculty@Score.Stanford.EDU
Message-ID: <12353491233.13.TOM@Score.Stanford.EDU>
Due to the recent disappearance of an Apple Laserwriter from the NA group,
I highly urge everyone to keep a look-out for suspicious person/persons who may
be walking out with something under their arms, like equipment. If you
do see someone, please call the police, phone number 9-911.
Make sure that your office door is locked and completely closed when
leaving for the long weekend.
thanks
tom
-------
∂25-Nov-87 1431 morris@navajo.stanford.edu PODS abstract available
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 25 Nov 87 14:30:22 PST
Received: by navajo.stanford.edu; Wed, 25 Nov 87 14:25:03 PST
Date: Wed, 25 Nov 87 14:25:03 PST
From: Kathy Morris <morris@navajo.stanford.edu>
Subject: PODS abstract available
To: nail@navajo.stanford.edu
``An Algorithm for Ordering Subgoals in NAIL!'', Katherine Morris,
Stanford.
The algorithm given in this extended abstract finds a feasible order
for the subgoals of a rule in time polynomial in the size of the rule,
for fixed arity. The algorithm is used in the NAIL! system for
generating rule-goal graphs.
∂26-Nov-87 0124 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #93
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 26 Nov 87 01:24:47 PST
Date: Wed 25 Nov 1987 05:04-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #93
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Thursday, 26 Nov 1987 Volume 5 : Issue 93
Today's Topics:
Implementation - Constraint LP & Algorithmic Debugging,
& Transitive Closure
----------------------------------------------------------------------
Date: 24 Nov 87 17:25:44 GMT
From: PT.CS.CMU.EDU!A.GP.CS.CMU.EDU!spiro@cs.rochester.edu (Spiro
Michaylov)
Subject: Constraint Logic Programming info sought
As one of the four implementors of the CLP(R) system developed at Monash
University in 1986, I'd like to provide some pointers for getting information
on CLP.
The system that we developed in 1986 was an interpreter, and our current
research is largely on compilation issues -- although no compiler is as yet
available.
The source code for the interpreter is being licensed by Monash University,
and further information on obtaining it can be requested from:
ACSNET: clp@moncsbruce.oz
ARPANET,CSNET: clp@moncsbruce.oz.au
UUCP: seismo!munnari!moncsbruce.oz!clp
If all else fails: munnari!moncsbruce!clp@uunet.UU.NET .
CLP(R) Distribution
Department of Computer Science
Monash University
Clayton
Victoria 3168
It is NOT in the public domain, and to my knowledge no other implementation
exists.
The list of implementors with addresses is given below. All of us would be
more than happy to answer questions about the CLP scheme, the CLP(R) system,
etc. Additionally, I would be glad to send copies of any or all of the
relevant publications to anybody who is interested.
Joxan Jaffar
H1-D46,
IBM Thomas J. Watson Research Center,
PO Box 704,
Yorktown Heights, NY 10598
( joxan@ibm.com )
Spiro Michaylov
Department of Computer Science,
Carnegie-Mellon University,
Pittsburgh, PA 15213
( spiro@a.gp.cs.cmu.edu )
Peter Stuckey and Roland Yap
Department of Computer Science,
Monash University,
Clayton, 3168
Victoria,
AUSTRALIA
( munnari!moncsbruce!pjs@uunet.UU.NET )
( munnari!moncsbruce!roland@uunet.UU.NET )
Further information can be found in the following papers:
1. J. Jaffar and J-L. Lassez, "Constraint Logic
Programming", Proc. 14th ACM-POPL, Munich, January
1987.
2. J. Jaffar and S. Michaylov, "Methodology and
Implementation of a CLP System", Proc. 4th ICLP,
Melbourne, May 1987.
3. N.C. Heintze, S. Michaylov and P.J. Stuckey, "CLP(R)
and Some Electrical Engineering Problems", Proc. 4th
ICLP, Melbourne, May 1987.
4. C. Lassez, K. McAloon and R. Yap, "Constraint Logic
Programming and Option Trading", IEEE Expert, Fall
Issue 1987.
Disclaimer:
While I am continuing to do research in this area, I no longer
have any affiliation with Monash University. The licensing of the
CLP(R) system is a non-commercial venture in which I have
no involment beyond giving people pointers.
------------------------------
Date: Tue, 24 Nov 87 16:24:47 PST
From: quintus!ok@Sun.COM (Richard A. O'Keefe)
Subject: Reply to Dongwook Shin
Dongwook Shin presents the program
g(X, Y) :- even(X), Y is X//2.
g(X, X).
To paraphrase him, he says that "the user may take the second clause as
being correct, because he may think that it is executed only when the
first clause fails. That is, he thinks the second clause is equivalent to
g(X, X) :- \+ even(X).
However, we might not blame him, as the one to be blamed is the non-fair
search mechanism in Prolog, and he is only a victim of this mechanism."
No, this hypothetical user is not a victim of any mechanism. He is
simply WRONG. If Dongwook Shin will refer back in the Digest to the
issue where I discussed various kinds of problems, he will find that I
called this "backwards incorrectness". [Please suggest a better name.]
If the programmer's intention was to realise the relation
g(X, Y) iff X and Y are integers and
X is even and 2Y = X or
X is odd and Y = X
then the program as written is just plain WRONG, whether you are using
forwards chaining, backwards chaining, top-down evaluation, bottom-up
evaluation, SLD, Earley Deduction, or are tossing yarrow stalks.
Dongwook Shin's point was that there were two mistakes. The other one is
even(X) :- X mod 3 =:= 0.
rather than the intended
even(X) :- X mod 2 =:= 0.
and he would like the debugger to help find this mistake, rather than
focussing on the second clause of g/2. But he should note that
correcting even/1 does NOT render the whole program correct! The
"corrected" program is
g(X, Y) :- X mod 2 =:= 0, Y is X // 2.
g(X, X).
THAT program is incorrect. Even with the "sequential" strategy that
Dongwook Shin sneers at, the second clause WILL be used, and it WILL
give the wrong answer. Surely we want a debugging tool that will help
us notice this blunder rather than one which will look the other way and
pretend that a mistake is not a mistake?
Having once again demonstrated that I can write more exposition
on a smaller subject than anyone else :-), I now return you to
your regular netnews. [Chris Torek]
------------------------------
Date: Wed, 25 Nov 87 12:55:05 EST
From: munnari!mulga.oz.au!lee@uunet.UU.NET (Lee Naish)
Subject: Algorithmic debugging
> Will Lee Naish also attack this policy with his electronic
> butcher's knife?
(I wasnt going to, but since you insist...:-)
In the program you gave g(X,X) is wrong (with respect to the user's
intended interpretation), whether the user's brain is contaminated with
Prolog's sequentiality, LSD, television or nothing at all. A
declarative debugger should tell you this.
The original program you gave had two bugs. The declarative debugging
work that I know of only attempts to look for one bug at a time. This
can greatly reduce the search space of the debugger (if it is written in
the right way), so that if the user gives inconsistent answers the
debugger fails instead of searching for other possible bugs.
After fixing one bug, you can go on to fix the others.
In your example, you fix one bug and say the other bug does not show up
after that. This is wrong - you need to consider all answers, not just
the first one.
There are several ways heuristic knowledge about common kinds of bugs
can be used. For example, discovering exactly what is wrong with an
incorrect clause (eg, missing a test), guiding the search of the
debugger (eg, trying clauses in reverse order) or just static analysis
(eg, detecting clauses which subsume other clauses). These could all be
helpful in the example you gave, without denying not g(2,2) => not all X
g(X,X).
We are currently doing some work on integrating several of the debugging
tools we (and others) have developed, including type checkers (we have
five so far!), other static analysers and "dynamic" tools such as
declarative debuggers, spy points, etc.
-- Lee
------------------------------
Date: Tue, 24 Nov 87 11:21:16 GMT
From: Fernando Pereira <pereira%cam.sri.com@drakes.ai.sri.com>
Subject: Old Chestnuts, Transitive Closure
The problems discussed by Richard O'Keefe and previous contributors have
been extensively studied by researchers in the area of deductive databases.
It is worth starting with
@ARTICLE{ullman,
AUTHOR = {Jeffrey D. Ullman},
TITLE = {Implementation of Logical Query Languages for Databases},
JOURNAL = {{ACM} Transactions on Database Systems},
YEAR = {1985},
VOLUME = {10},
NUMBER = {3},
PAGES = {289-321}
}
and then look at more recent papers on the same subject by Bancillon,
Zaniolo, Ullman and others. Basically, these authors consider specialized
efficient (eg. polynomial) proof procedures whose applicability to
solving a particular query can be decided by program analysis algorithms.
-- Fernando Pereira
------------------------------
End of PROLOG Digest
********************
∂29-Nov-87 1424 X3J13-mailer subcommittees
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 29 Nov 87 14:24:00 PST
Date: 29 Nov 1987 17:22-EST
Sender: MATHIS@A.ISI.EDU
Subject: subcommittees
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]29-Nov-87 17:22:16.MATHIS>
here is my version of how the subcommittee evolved at the Ft. Collins
meeting. PLEASE send me any additions or other corrections.
If you have an electronic mailing list, please let me know and tell
me how people outside the subcommittee should be involved with that
list (if at all)
X3J13 Subcommittees (as of November 29, 1987
(Mathis, Steele, and Gabriel try to follow all)
Editorial:
Kathy Chapman, chair
Ron Ohlander
Mary Boelk
Dick Gabriel
Kent Pitman
Walter van Roggen
Skona Brittain
Character Subcommittee <cl-natural-languages
Thom Linden, chair (IBM Research)
Larry Masinter (XEROX Research)
Carl Hoffman (International Lisp Associates)
Bob Kerns (Symbolics)
Duncan Missimer (Hewlett-Packard)
Dave Matthews (Hewlett-Packard)
Mike Beckerle (Gold Hill)
Kevin Layer (Franz)
ISO/IEC JTC1/SC22/WG 16 Delegation:
Dick Gabriel, chair
Guy Steele
Bob Mathis
Patrick Dussud
Thom Linden
Larry Masinter
Will Clinger
Bill Scherlis
Kent Pitman
John McCarthy
Iteration
Jon L. White, chair
Pavel Curtis
Chris Purdue
Dan Weinreb
Errors and Conditions
Kent Pitman, chair
Andy Daniels
Validation and Conformance
--, chair
David Slater
Mike Beckerle
Chris Dambroski
Compiler Specification
Steve Haflich, chair
David Bartley
Mike Beckerle
Rob McLaughlin
Walter van Roggen
CLOS
Danny Bobrow, chair
David Moon
Dick Gabriel
Gregor Kiczales
Linda DeMichiel
Sonya Keene
Patrick Dussud
Jim Kempf
Lisp1/Lisp2
Dick Gabriel
Will Clinger
Kent Pitman
Mark Wegman
Richard Greenblat
Dan Weinreb
Macros
Mark Wegman
Julian Padget
Steve Haflich
Kent Pitman
Graphics and Windows
Erik Schoen, chair
George Haden
Ellen Waldrum
Types & Declarations
Bill Scherlis
Clean-up
Larry Masinter
Guy Steele
Kent Pitman
JonL White
Scott Fahlman
David Moon
Ellen Waldrum
Meeting Planning
Jan Zubkoff
∂29-Nov-87 1432 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU visiting committee
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Nov 87 14:32:19 PST
Received: from Tenaya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 29 Nov 87 14:25:39-PST
Received: by Tenaya.Stanford.EDU (3.2/SMI-3.2)
id AA01490; Sun, 29 Nov 87 14:30:43 PST
Date: Sun, 29 Nov 87 14:30:43 PST
From: nilsson@Tenaya.Stanford.EDU (Nils Nilsson)
Message-Id: <8711292230.AA01490@Tenaya.Stanford.EDU>
To: faculty@score
Subject: visiting committee
Attached is a first-draft schedule for the visiting committee. Please
send comments/suggestions with a cc to George Wheaton (wheaton@athena).
Thanks, -Nils
----------
Tentative Agenda for the Computer Science Department Visiting Committee
February 2 and 3, 1988
Visiting Committee Members
Dr. Sam Fuller, Digital Equipment Corporation (Chair of Committee)
Dr. Al Aho, ATT Bell Laboratories
Professor Barbara Grosz, Computer Science Dept., Harvard University
Dr. Robert Kahn, National Research Institute
Dr. Robert Sproull, Sutherland Sproull Associates
Prof. Joel Moses, EECS, MIT
Monday, February 1, 1988 (for those committee members who will be in
town and can attend):
6:30 pm Dinner hosted by Nils Nilsson
Tuesday, February 2, 1988
8:00 - 11:30 Overview (Breakfast provided)
Invitees: Dean James Gibbons, Dean Robert Eustis, Dean Elliott Levinthal,
Nils Nilsson, George Wheaton, Carolyn Tajnai, Stuart Reges,
James Ball
Agenda:
Overview of SOE and the Place of CS in the School -Jim Gibbons
Discussion of Charge to the Committee
Overview of the Stanford Computer Science Dept. -Nils Nilsson
Organization and Major Research Areas
Budgets and Plans
New Buildings
Participating Centers and Labs
Affiliates Program -Carolyn Tajnai
Computer Facilities -Jim Ball
Educational Program -Stuart Reges
11:30 Tour of CSD Educational Facilities at Tressider Union
12:00-1:30 Working lunch with the CS Faculty, Margaret Jacks Hall, Rm 146
Agenda: Brief Overviews of B.S., M.S., MSAI, PhD Programs
2:00-4:00 Tour of Knowledge Systems Lab and KSL Presentations
(Transportation on arranged mini-bus)
4:00-6:00 Tour of CIS and CSL presentations
7:00-9:00 Dinner with faculty from Foundations of Computer Science
and Scientific Computing
Invitees: Knuth, Floyd, Manna, Goldberg, Pratt, Mayr, Oliger,
Mitchell, Ullman, Guibas, Nilsson
Wednesday, February 3, 1988
8:30-10:00 Tour of Robotics Laboratory at Cedar Hall
(Continental breakfast provided)
Description of AI and Robotics Research
Invitees: Latombe, Binford, McCarthy,
Genesereth, Shoham, Nilsson, Feigenbaum, Buchanan
Walk to Margaret Jacks Hall
10:15-11:00 Meeting with undergraduates
11:00-12:00 Meeting with M.S. and MSAI students
12:00-1:30 Lunch/Meeting with PhD students
1:30-3:00 Meetings with Junior Faculty
3:00-5:00 Wrap-up -Gibbons, Nilsson, (Rosse?)
6:30 p.m. Dinner
Other: Would it be a good idea for the committee to have
a private few minutes with staff representatives?
I'll be asking George to get some written material from some of you
that can be sent to the visitors before their arrival (for airplane
reading) so that we can make optimum use of time while they are
here.
∂30-Nov-87 0927 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU faculty lunch
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Nov 87 09:27:23 PST
Received: from Tenaya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 30 Nov 87 09:17:56-PST
Received: by Tenaya.Stanford.EDU (3.2/SMI-3.2)
id AA02090; Mon, 30 Nov 87 09:22:58 PST
Date: Mon, 30 Nov 87 09:22:58 PST
From: nilsson@Tenaya.Stanford.EDU (Nils Nilsson)
Message-Id: <8711301722.AA02090@Tenaya.Stanford.EDU>
To: faculty@score
Subject: faculty lunch
At tomorrow's faculty lunch (Tues, Dec. 1) our guest will be
Maria Klawe from IBM Almaden. She will also be visiting with
various faculty members during the day---talking about our
experiences with IBM RT's. -Nils
∂30-Nov-87 1159 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talks
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Nov 87 11:59:36 PST
Date: Mon 30 Nov 87 11:49:09-PST
From: Anil R. Gangolli <GANGOLLI@Sushi.Stanford.EDU>
Subject: Upcoming AFLB Talks
To: aflb.all@Sushi.Stanford.EDU
Office Phone: (415) 723-3605
Message-ID: <12354801053.25.GANGOLLI@Sushi.Stanford.EDU>
THIS WEEK'S TALK:
3-December-87: Noam Nisan (UC Berkeley)
Probabilistic vs. Deterministic Decision Trees
and CREW PRAM complexity
In the boolean decision tree model the only cost associated with an
algorithm is the number of input bits examined. We compare the
deterministic versus probabilistic complexities of boolean functions
in this model, both for 1-sided error probabilistic computation and
for 2-sided error computation. In both cases we show a polynomial
relationship.
Our techniques involve the new notion of the "block sensitivity" of a
function, a generalization of the critical sensitivity measure. They
apply to a completely different model of computation as well: the CREW
PRAM. We show that the block sensitivity completely characterizes the
complexity in the CREW PRAM model (with an unbounded number of
processors). We get that the parallel time it takes to compute f on a
CREW PRAM with an unlimited number of processors is equal (up to a
constant factor) to the logarithm of the boolean decision tree
complexity of f.
*** Time and Place: 12:30pm, Thurs., Dec. 3 MJH (Bldg 460), Room 352 ***
NEXT WEEK'S TALK:
10-December-87: John Canny (Berkeley)
Robot Motion Planning and Real Geometry
The goal of this work is to come up with fast motion planning
algorithms, in both a formal and practical sense, which have some kind
of performance guarantee. The main result is for the generalized
movers' problem, which is motion planning for an arbitrary robot with
kinematic constraints only. I will present an algorithm for this
problem called the ``roadmap algorithm'' which equals or improves the
bounds of most of the special purpose exact algorithms that have
appeared over the last few years. The algorithm also involves lower
constants than the others and is a plausible candidate for
implementation. I will also consider motion planning with dynamic
constraints, minimal motion planning, and motion planning with
uncertainty, and give new lower bounds for these problems. The lower
bound results are joint work with John Reif of Duke university.
The roadmap algorithm is in effect a decision algorithm for the first
order existential theory of real numbers. It makes use of results in
singularity theory, in particular the notion of stratified sets, which
provide a very natural and efficient way to represent geometric
objects. It also uses a new (actually very old but obscure) algebraic
tool called the multivariate resultant. This latter tool gives a fast
parallel method for solving systems of equations, and should give
improvements in algorithms for inverse kinematics, CSG modeling, and
geometric theorem proving.
*** Time and Place: 12:30pm, Thurs., Dec. 10, MJH (Bldg 460), Room 352 ***
-------
∂30-Nov-87 1343 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU Gray Tuesday
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Nov 87 13:43:37 PST
Received: from Tenaya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 30 Nov 87 13:37:46-PST
Received: by Tenaya.Stanford.EDU (3.2/SMI-3.2)
id AA02528; Mon, 30 Nov 87 13:42:47 PST
Date: Mon, 30 Nov 87 13:42:47 PST
From: nilsson@Tenaya.Stanford.EDU (Nils Nilsson)
Message-Id: <8711302142.AA02528@Tenaya.Stanford.EDU>
To: ac@score
Subject: Gray Tuesday
As I'm sure Sharon Hemenway has already announced to the faculty,
Gray Tuesday will occur on Tuesday, Dec. 8, 1987 at 2:30 p.m. in
mjh 252. Please come prepared to discuss the progress of your students
and to help us decide on any needed recommendations concerning
student progress. Mike Genesereth, as PhD committee chair, will chair
the meeting---assisted by Sharon Hemenway. -Nils
∂30-Nov-87 1618 TAJNAI@Score.Stanford.EDU Nominations for AT&T Fellowship
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Nov 87 16:18:10 PST
Date: Mon 30 Nov 87 16:11:44-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Nominations for AT&T Fellowship
To: faculty@Score.Stanford.EDU
cc: hayes-roth@SUMEX-AIM.Stanford.EDU
Message-ID: <12354848856.37.TAJNAI@Score.Stanford.EDU>
After a great deal of deliberating, we are nominating:
Craig Chambers - Systems
David Salesin - Foundations
Michael Wolverton - AI
Thank you for your thoughtful messages. It was a tough job to make
the selections. Our students are really impressive.
Carolyn
-------
∂30-Nov-87 1717 SLOAN@Score.Stanford.EDU Xerox Machines
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Nov 87 17:17:04 PST
Date: Mon 30 Nov 87 17:05:32-PST
From: Yvette Sloan <SLOAN@Score.Stanford.EDU>
Subject: Xerox Machines
To: CSD-List@Score.Stanford.EDU
Message-ID: <12354858649.18.SLOAN@Score.Stanford.EDU>
This is to inform you that, due to our switch over to electronic auditrons,
the Xerox machines in MJH will be done for a short period of time tomorrow
beginning at 1:30.
-------
∂01-Dec-87 0026 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #94
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 87 00:26:40 PST
Date: Mon 30 Nov 1987 07:38-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #94
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Tuesday, 1 Dec 1987 Volume 5 : Issue 94
Theory - Impediments,
Implementation - Chestnuts
----------------------------------------------------------------------
Date: 25 Nov 87 22:23:04 GMT
From: aramis.rutgers.edu!chomicki@rutgers.edu (Jan Chomicki)
Subject: Theoretical impediments to logic programming?
Rabin and Fischer's result about the inherent complexity of Presburger
arithmetic has no relevance for Prolog. In Prolog you can not write
most of the sentences of this arithmetic, because of the lack of:
- arbitrary quantification.
- equations, like y=x+x.
- propositional connectives 'not' and 'or'.
SLD-resolution (or for that matter any resolution method alone)
can not handle Presburger arithmetic. It is quite possible
that the arithmetic hacks (like is/2) with which we have to live
were born out of their designers' fear of the inherent complexity
(or even undecidability if both + and * are allowed) of arithmetic.
The complexity results relevant for Prolog can be found in papers about
the satisfiability problem for propositional and first order formulas
( Lewis 1980, Plaisted 1984: both in Journal of Computer and System
Sciences). And those results confirm a special role of Horn clauses.
For example, satisfiability of propositional Horn clauses is in P as
opposed to the general case which is NP-complete.
-- Jan Chomicki
------------------------------
Date: 26 Nov 1987 1707-WET (Thursday)
From: Jamie Andrews <jha%cstvax.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Narain's comments on Presburger and Logic Programming
Sanjay Narain enters an interesting area in his discussion of
Rabin's result about the structural complexity of Presburger
arithmetic. But let me first just correct some of his assumptions:
1. The Horn clausal calculus is _not_ richer than Presburger
arithmetic. PrA is a first-order theory, and thus has universal
quantifier and negation, which Horn clauses don't have.
(Though some may not realise this, the problems of getting
'forall' and 'not' into Prolog have not been solved.)
2. SLD-resolution is not a decision procedure, in the sense that
Rabin was probably using it, because it is not deterministic.
This is a kind of picky point, because I assume Sanjay meant
``the usual sequential implementation of SLD-resolution''
wherever he used the term.
Now we may be able to see why Prolog and similar systems escape
Rabin's net. They are not only not trying to solve PrA efficiently,
they are not trying to solve any first-order theory at all! They
are just trying to solve a subset of a first-order theory derived
from the program. The precise subset they are trying to solve is
something I'm working on finding.
I agree with Sanjay, though, that sequential logic programming
systems involve the notion of (sequential) algorithm in a way that
is hard to model in pure logic. This is quite a stumbling-block
in trying to apply pure logic to logic programming.
--Jamie.
------------------------------
Date: Wed, 25 Nov 87 13:16:11 CST
From: raghu@cs.wisc.edu (Raghu Ramakrishnan)
Subject: follow-up to a posting
This is being worked on by a lot of people in the database community.
For a survey and comparison of several strategies (mostly bottom-up,
but including Prolog) on a small set of programs including various
versions of transitive closure, see the paper by Bancilhon and
Ramakrishnan in SIGMOD 86, "An Amateur's Introduction to Recursive
Query Processing Strategies." The paper makes observations similar
to O'Keefe's regarding Prolog, and provides some numbers to go with them.
A revised version with more details about the performance comparisons
(to appear in a book edited by Minker, "Foundations of Logic Programming
and Deductive Databases") is also available, and you can get a copy from
me. (I'd appreciate your looking at the SIGMOD version first to see if
you're interested! :-))
-- Raghu Ramakrishnan
------------------------------
End of PROLOG Digest
********************
∂01-Dec-87 0950 STAGER@Score.Stanford.EDU Portia/Watson/Jessica
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 87 09:50:39 PST
Date: Tue 1 Dec 87 09:43:40-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: Portia/Watson/Jessica
To: instructors@Score.Stanford.EDU, tas@Score.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12355040355.28.STAGER@Score.Stanford.EDU>
Portia, Watson and Jessica will be down this Friday, December 4. Contact
Sean Welsh at LOTS with any questions or concerns.
-------
∂01-Dec-87 1031 RICHARDSON@Score.Stanford.EDU Library Services Check-List for the Near West Campus
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 87 10:31:02 PST
Date: Tue 1 Dec 87 10:23:01-PST
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: Library Services Check-List for the Near West Campus
To: srstaff@Score.Stanford.EDU, faculty@Score.Stanford.EDU,
brown@SUMEX-AIM.Stanford.EDU, clancey@SUMEX-AIM.Stanford.EDU,
engelmore@SUMEX-AIM.Stanford.EDU, bhayes-roth@SUMEX-AIM.Stanford.EDU,
val@Sail.Stanford.EDU, nii@SUMEX-AIM.Stanford.EDU, sjg@Sail.Stanford.EDU,
ok@Sail.Stanford.EDU
Message-ID: <12355047519.13.RICHARDSON@Score.Stanford.EDU>
LIBRARY SERVICES CHECK-LIST
PLEASE INDICATE YOUR CHOICE OF THE DESIRABILITY OF THE LIBRARY SERVICES
FOR THE NEAR WEST CAMPUS BY PLACING A CHECK OR "X" IN THE APPROPRIATE BOX.
RETURN THIS FORM TO: RICHARDSON@SCORE FOR TRANSMITTAL TO REBECCA LASHER
LIBRARY SERVICES | essential | desirable | optional | not
| | | | needed
| | | |
1. Reference
| | | |
in person reference_____________|___________|___________|__________|________
| | | |
electronic mail reference_______|___________|___________|__________|________
| | | |
phone reference_________________|___________|___________|__________|________
| | | |
brief question (ready reference)|___________|___________|__________|________
| | | |
2. Circulation
| | | |
reserves________________________|___________|___________|__________|________
| | | |
journals________________________|___________|___________|__________|________
| | | |
books___________________________|___________|___________|__________|________
| | | |
videotapes______________________|___________|___________|__________|________
| | | |
books___________________________|___________|___________|__________|________
| | | |
technical reports_______________|___________|___________|__________|________
| | | |
software (course)_______________|___________|___________|__________|________
| | | |
software (other)________________|___________|___________|__________|________
| | | |
other (specify)_________________|___________|___________|__________|________
| | | |
3. Database searching
| | | |
with librarian__________________|___________|___________|__________|________
| | | |
on your own_____________________|___________|___________|__________|________
| | | |
4. Carrels
| | | |
Ph.D. students__________________|___________|___________|__________|________
| | | |
faculty/visiting professors_____|___________|___________|__________|________
| | | |
| | | |
5. Key or card access to Library__|___________|___________|__________|________
| | | |
6. Bibliographic Instruction Program
| | | |
database searching training_____|___________|___________|__________|________
| | | |
Socrates training_______________|___________|___________|__________|________
| | | |
Other library resources_________|___________|___________|__________|________
| | | |
Information management classes__|___________|___________|__________|________
| | | |
7. Classroom Capability for
| | | |
Bibliographic Instruction Program___________|___________|__________|________
(use of library materials) | | | |
| | | |
Students needs: videotape viewing___________|___________|__________|________
| | | |
Other (i.e. teleconferencing____|___________|___________|__________|________
| | | |
8. Microcomputers for:
| | | |
General public access___________|___________|___________|__________|________
| | | |
SUNET___________________________|___________|___________|__________|________
| | | |
Other___________________________|___________|___________|__________|________
| | | |
9. Photocopiers
| | | |
one copier for users____________|___________|___________|__________|________
| | | |
two copiers for users___________|___________|___________|__________|________
| | | |
10. Other equipment
| | | |
microfilm/microfiche reader-printer_________|___________|__________|________
| | | |
microfiche reader_______________|___________|___________|__________|________
| | | |
other (specify)_________________|___________|___________|__________|________
| | | |
11. Document Delivery Service
| | | |
on campus: electronic (fax)_____|___________|___________|__________|________
| | | |
on campus: Interlibrary loan____|___________|___________|__________|________
| | | |
12. User study areas
| | | |
conference rooms________________|___________|___________|__________|________
| | | |
Reserve reading area____________|___________|___________|__________|________
| | | |
late night study area___________|___________|___________|__________|________
| | | |
videotape viewing_______________|___________|___________|__________|________
| | | |
other (specify)_________________|___________|___________|__________|________
| | | |
13. IICE (Industrial Information Center)
for non-Stanford users
| | | |
document delivery_______________|___________|___________|__________|________
| | | |
other __________________________|___________|___________|__________|________
| | | |
14. Restrooms______________________|___________|___________|__________|________
| | | |
15. Translation Service____________|___________|___________|__________|________
| | | |
16. Telephones_____________________|___________|___________|__________|________
| | | |
17. Lockers________________________|___________|___________|__________|________
| | | |
18. Special needs (define)
19. Regarding the materials
| | | |
maintain a collection of all | | | |
formats needed in the library___|___________|___________|__________|________
| | | |
maintain only a core collection | | | |
of books, journals, tech rpts.__|___________|___________|__________|________
| | | |
archive older materials_________|___________|___________|__________|________
| | | |
maintain current newspapers_____|___________|___________|__________|________
| | | |
maintain current newsletters | | | |
selectively chosen, reviewed____|___________|___________|__________|________
| | | |
maintain special formats as | | | |
needed (media, catalogs, software)__________|___________|__________|________
| | | |
have a current periodicals area_|___________|___________|__________|________
| | | |
have a new book shelf area______|___________|___________|__________|________
| | | |
other___________________________|___________|___________|__________|________
| | | |
| | | |
20. Features the library should have/provide
access to other science/SUL | | | |
libraries via electronic mode___|___________|___________|__________|________
| | | |
access to other science/SUL | | | |
libraries via runners___________|___________|___________|__________|________
| | | |
provide a quiet area for reading| | | |
thinking________________________|___________|___________|__________|________
| | | |
provide workstations(s) for | | | |
working in the library accessing| | | |
library and individual databases/ | | |
files/the like__________________|___________|___________|__________|________
| | | |
| | | |
restrooms_______________________|___________|___________|__________|________
| | | |
conference rooms________________|___________|___________|__________|________
| | | |
classrooms______________________|___________|___________|__________|________
| | | |
media area______________________|___________|___________|__________|________
| | | |
computer clusters_______________|___________|___________|__________|________
| | | |
other
-------
-------
∂01-Dec-87 1041 @Score.Stanford.EDU:G.GORIN@MACBETH.STANFORD.EDU Re: Portia/Watson/Jessica
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 87 10:41:05 PST
Received: from MACBETH.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Tue 1 Dec 87 10:26:30-PST
Date: Tue 1 Dec 87 10:31:18-PST
From: Ralph Gorin <G.GORIN@MACBETH.STANFORD.EDU>
Subject: Re: Portia/Watson/Jessica
To: STAGER@SCORE.STANFORD.EDU
cc: instructors@SCORE.STANFORD.EDU, tas@SCORE.STANFORD.EDU,
G.GORIN@MACBETH.STANFORD.EDU
In-Reply-To: <12355040355.28.STAGER@Score.Stanford.EDU>
Message-ID: <12355049026.23.G.GORIN@MACBETH.STANFORD.EDU>
An amplification of Claire's message:
ALL of the LOTS systems, including the tragedies, will be down from 7
AM to 10 AM (planned) on Friday, December 4, because of an electrical
shutdown needed to effect the rewiring of the CERAS computer rooms.
We'll try to have computer services restored as quickly as
practicable.
Instructors who have assignments due on Friday should alert their
students to the impending down time.
Ralph Gorin
-------
∂01-Dec-87 1747 @relay.cs.net,@ai.toronto.edu:mendel@db.toronto.edu Jobs in Toronto
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 87 17:44:30 PST
Received: from RELAY.CS.NET by navajo.stanford.edu with TCP; Tue, 1 Dec 87 17:37:26 PST
Received: from ai.toronto.edu by RELAY.CS.NET id aa16251; 1 Dec 87 20:14 EST
Received: from melody.db.toronto.edu by ai.toronto.edu via ETHER with SMTP id AA15127; Tue, 1 Dec 87 20:06:41 EST
Received: from mendel by melody.db.toronto.edu via UNIX id AA06140; Tue, 1 Dec 87 20:11:24 EST
Date: Tue, 1 Dec 87 20:11:24 EST
From: Alberto Mendelzon <mendel%db.toronto.edu@relay.cs.net>
Message-Id: <8712020111.AA06140@melody.db.toronto.edu>
To: nail@navajo.stanford.edu
Subject: Jobs in Toronto
The Computer Science Department at the University
of Toronto is looking for regular faculty, research
associates, and postdoctoral fellows. The area of
databases/knowledge bases is of particular interest.
If you are interested or know someone who is, please
let us hear from you.
-Alberto Mendelzon
mendel@csri.toronto.edu
416-978-2952
∂02-Dec-87 0135 LOGMTC-request Wednesday seminar on dynamic types
Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 87 01:35:17 PST
Received: from sun.Sun.COM by Sun.COM (4.0/SMI-3.2)
id AA08456; Wed, 2 Dec 87 01:35:59 PST
Received: from coraki.UUCP by sun.Sun.COM (4.0/SMI-4.0)
id AA09917; Wed, 2 Dec 87 01:36:29 PST
Received: by coraki.uucp (3.2/SMI-1.2)
id AA04110; Wed, 2 Dec 87 01:32:39 PST
Date: Wed, 2 Dec 87 01:32:39 PST
From: coraki!pratt@Sun.COM (Vaughan Pratt)
Message-Id: <8712020932.AA04110@coraki.uucp>
To: conmod@navajo.stanford.edu, friends@csli.stanford.edu,
logmtc@sail.stanford.edu
Subject: Wednesday seminar on dynamic types
Cc: coraki!pratt@Sun.COM
(Sorry about the short notice, but the subject barely existed before
yesterday.)
Title: Dynamic Types
Speaker: Vaughan Pratt
Time: 10:00 am
Date: Wednesday December 2
Place: MJ301
Abstract:
Given a monoidal category D of delays and a concrete category T of
types we construct the concrete category D |> T of dynamic types over D
and T. A dynamic type is a graph whose edges are labeled with delays
in D, whose vertices are labeled with values of a type in T, and which
is equipped with the structure of a concrete category naturally derived
from the structures of D and T. Dynamic types were initially developed
as a uniform semantic base for concurrent programming languages and
their logics, but have found a surprising application at the
foundations of mathematics as an efficient and constructive source of a
very large collection of familiar concepts as diverse as multisets,
modal logics, metric spaces, Floyd-style proofs of programs, and linear
time. We consider some of the philosophical implications for theories
that combine time and truth.
∂02-Dec-87 0721 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Reference wanted for article on distfix tokens
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 87 07:21:23 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Wed 2 Dec 87 07:14:42-PST
Received: by lindy.stanford.edu; Wed, 2 Dec 87 07:18:03 PST
Received: by Forsythe.Stanford.EDU; Wed, 2 Dec 87 07:18:48 PST
Received: by NDSUVM1 (Mailer X1.24) id 3952; Wed, 02 Dec 87 08:56:28 CST
Date: 2 Dec 1987 09:47:28-EST (Wednesday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Norbert Vogl <GONDOR.PSU.EDU!NORBERT%PSUVAX1.PSU.EDU@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Norbert Vogl <GONDOR.PSU.EDU!NORBERT%PSUVAX1.PSU.EDU@forsythe.stanford.edu>
Subject: Reference wanted for article on distfix tokens
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
I am looking for a reference to an article about distfix operators.
This article showed how to have a (lexical scanner / compiler) pair
such as lexx and yacc accept distfix tokens in a general manner.
For an if statement with distfix tokens, it would accept:
.if <expr> .then. <stmts>
.else. <stmts>
end.
The scanner would recognize the distfix tokens because of the periods.
I've looked through SIGPLAN back until 1974 and haven't found the article
so either I missed it or it appeared in some other journal.
If anybody has heard of this article please write to me and tell me where I
can find it. I want to use it as a reference for a paper I am writing.
I think it was called something like "Dynamic distfix operators" but I may
be wrong.
Thank you,
Norbert Vogl
(norbert@gondor.psu.edu or psuvax1!gondor!norbert)
∂02-Dec-87 0836 RICHARDSON@Score.Stanford.EDU Faculty Meeting
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 87 08:36:26 PST
Date: Wed 2 Dec 87 08:29:37-PST
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: Faculty Meeting
To: faculty@Score.Stanford.EDU
Message-ID: <12355289017.12.RICHARDSON@Score.Stanford.EDU>
There will be a faculty meeting on Tuesday, January 5 at 2:30 to vote on
degree candidates and a proposed change in the policy regarding the CSD's
share of invention income. Should you have any suggestions for additional
agenda items, please send them to me. (Details on the location will follow.)
-Anne
-------
∂02-Dec-87 0842 RICHARDSON@Score.Stanford.EDU Sr. Faculty Meeting
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 87 08:42:05 PST
Date: Wed 2 Dec 87 08:31:08-PST
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: Sr. Faculty Meeting
To: tenured@Score.Stanford.EDU
Message-ID: <12355289295.12.RICHARDSON@Score.Stanford.EDU>
There will be a sr. faculty meeting immediately following the general
faculty meeting on Tuesday, January 5 (which starts at 2:30) to discuss
the Mayr promotion case.
-Anne
-------
∂02-Dec-87 0939 ullman@navajo.stanford.edu PODS papers accepted
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 87 09:38:25 PST
Received: by navajo.stanford.edu; Wed, 2 Dec 87 09:27:29 PST
Date: Wed, 2 Dec 87 09:27:29 PST
From: Jeff Ullman <ullman@navajo.stanford.edu>
Subject: PODS papers accepted
To: nail@navajo.stanford.edu
The following is a list of the papers accepted for the 1988 PODS.
According to the program chairman, Mihalis Yannakakis, the list is
in order of receipt of the submission.
I am proud to see that two of my students bring up the tail of this
list. If I teach them one thing, its that deadlines are for people
with nothing better to do than write abstracts.
---jeff
**************************************************
Udo Kelter
The queue protocol: a deadlock-free, homogeneous, non-two-phase locking protocol
Bing-Chao Huang and Michael A. Langston
Stable set and multiset operations in optimal time and space
Edward P. F. Chan and Hector J. Hernandez
Independence-reducible database schemes
Phokion G. Kolaitis and Christos H. Papadimitriou
Why not negation by fixpoint?
Oded Shmueli, Shalom Tsur and Carlo Zaniolo
Rewriting of rules containig set terms in a logic data language (LDL)
M. Muralikrishna and David J. De Witt
Optimization of multiple-relation multiple-disjunct queries
Lin Yu and Daniel J. Rosenkrantz
Minimizing time-space cost for database version control
Thanasis Hadzilacos and Vassos Hadzilacos
Transaction Synchronisation in object bases
Stephen J. Hegner
Decomposition of relational schemata into components defined by both projection and restriction
Maurice P. Herlihy and William E. Weihl
Hybrid concurrency control for abstract data types
Jeffrey D. Ullman and Moshe Y. Vardi
The complexity of ordering subgoals
Marianne Winslett
A framework for comparison of update semantics
M. V. Ramakrishna and P. Mukhopadhyay
Analysis of bounded disorder file organization
Ramsey W. Haddad and Jeffrey F. Naughton
Counting methods for cyclic relations
Thanasis Hadzilacos
Serialization graph algorithms for multiversion concurrency control
Jaideep Srivastava and Doron Rotem
Analytical modeling of materialized view maintenance
Seppo Sippu and Eljas Soisalon-Soininen
A generalized transitive closure for relational queries
D. S. Batory
Concepts for a database system synthesizer
Richard Hull and Jianwen Su
On the expressive power of database queries with intermediate types
Moshe Y. Vardi
Decidability and undecidability results for boundedness of linear recursive queries
Raghu Ramakrishnan, Catriel Beeri and Ravi Krishnamurthy
Optimizing existential datalog queries
Shamim Naqvi and Ravi Krishnamurthy
Database updates in logic programming
Serge Abiteboul and Victor Vianu
Procedural and declarative database update languages
Jan Paredaens and Dirk Van Gucht
Possibilities and limitations of using flat operators in nested algebra expressions
Tomasz Imielinski and Shamim Naqvi
Translating specifications into stratified programs
Jan Chomicki and Tomasz Imielinski
Temporal deductive databases and infinite objects
Wen-Chi Hou, Gultekin Ozsoyoglu and Baldeo K. Taneja
Statistical estimators for relational algebra expressions
Peter Buneman, Susan Davidson and Aaron Watters
A semantics for complex objects and approximate queries
Gabriel M. Kuper
On the expressive power of logic programming languages with sets
Michael Kifer, Raghu Ramakrishnan and Avi Silberschatz
An axiomatic approach to deciding query safety in deductive databases
Vladimir Lanin and Dennis Shasha
Concurrent set manipulation without locking
Katherine A. Morris
An algorithm for ordering subgoals in NAIL!
Allen Van Gelder and Kenneth Ross
Unfounded sets and well-founded semantics for general logic programs
∂02-Dec-87 1545 X3J13-mailer 11-87 minutes
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 87 15:44:53 PST
Received: by labrea.stanford.edu; Wed, 2 Dec 87 15:41:10 PST
Received: from sunvalleymall.lucid.com by edsel id AA11888g; Wed, 2 Dec 87 15:35:55 PST
Received: by sunvalleymall id AA08895g; Wed, 2 Dec 87 15:35:59 PST
Date: Wed, 2 Dec 87 15:35:59 PST
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8712022335.AA08895@sunvalleymall.lucid.com>
To: x3J13@sail.stanford.edu
Subject: 11-87 minutes
Plans for March meeting to follow.
X3J13/87-038
Minutes
Ft. Collins, CO
11/17/87 - 11/18/87
Item 1: Call to Order, Bob Mathis
9:00 am - Tuesday, November 17, 1987. Ft. Collins meeting called to order.
Introductory remarks. Attendance list send around. Introduction of
attendees.
Item 4: Report on ISO Ballot (Doc: 87-031), Bob Mathis
Letter from Bob Mathis to Catherine Kachurick. Letter from Thomas Turba to
Bob Mathis. Letter from Catherine Kachurick to X3. Preliminary Draft of
ISO/IEC JTC 1 Information Technology Secretariat: USA (ANSI). Summary of
Voting Document. Proposed comments from US on the name for the resulting
ISO standard on LISP. Draft UK Position on LISP.
Item 2: Approval of Agenda, Bob Mathis
Proposed agenda (X3J13/87-037) approved with minor changes. No windows and
a shorter CLOS discussion.
Item 5: Other administrative matters, Bob Mathis
New document register is available. List of subcommittees (please send
Mathis changes of members and send electronic mailing address). X3 bills
have been sent out. Make checks for this meeting payable to Hewlett Packard
and give to Dave Matthews during break. Dinner will be at 6:30pm.
Item 8: Characters, Thom Linden Committee name and scope. Name change
Natural Language Committee to Character Committee. JEIDA acknowledgement
and interaction network. IBM proposal. Thom will have a detailed proposal
at the March meeting. Committee will discuss one topic at a time. Bob
Mathis will forward ISO character notes to Thom Linden.
Item 9: Iteration, JonL White
Work promised on MIT LOOP at Cambridge meeting has just begun. Discussion
on whether standard is needed for portable loops. Discussion on why loop
and do standards may be necessary for new programmers.
Item 10: Lisp1/Lisp2, Common Lisp and Scheme, Will Clinger
Discussion on denotational semantics. Should we dissolve the Lisp1/Lisp2
committee? Should we broaden the committee to look at semantics of the
entire language? We need to take a vote.
11:30am - Morning Break
Item 12: Reports from other subcommittees
Errors, Kent Pitman
No new revisions. Will send mail with questions posed since last meeting.
Will have proposal for approval at next meeting.
12:00 - Lunch
Item 11: Editorial, Kathy Chapman
Discussed whether spec should be CLtL with changes or start from scratch.
Presented idea of 2 manuals, one a formal spec and one a rationale manual.
We need to decide what the deadline for the manual is.
2:30 pm - Break
Item 12: Reports from other subcommittees
Macros, Julian Padget
Brief overview. Please send examples of hairy macros to Julian Padget. A
brief summary will be available at next meeting.
Item 12: Reports from other subcommittees
CLOS, Gregor Kiczales
Committee has filled in chapters 1 and 2. Chapter 3 will be decided in
December at a Meta Objects meeting in Boston. Changes include: loosened
lambda-list congruence rules, instance creation and initialization,
simplified with-slots, handling some exception conditions, and lexical
generic functions. Next revision will be available in February 1988.
Please send comments via net-mail by end of February so changes can be made
by the March meeting.
Item 12: Reports from other subcommittees
Validation, Bob Mathis
Rich Berman has left ISI. This leaves the validation committee unmanned.
Item 12: Reports from other subcommittees
Type and Declaration, Bob Mathis
Bill Scherlis was to report. Nothing has been reported.
4:15pm - Break
4:25pm - Bob Mathis proposed the agenda for Wednesday's meeting be 9:00 -
10:30 Cleanup Committee, wrapping up by lunch and have committee meetings
after lunch.
Item 14: Extended Discussion on CLOS and Clean-up, Larry Mascinter
General remarks and review issue status. Intent is writing for editor the
go-ahead on issues. Ran quickly through issues.
Item 15: Recess, 4:55pm
Item 16: Call to Order, November 18, 8:59am, Bob Mathis
Item 17: Further discussions on cleanup and drafting, Larry Mascinter
The following people contributed issues and discussions but are not on the
clean-up committee. We thank them for their participation.
Dan Carnese Schlumberger
Will Clinger Tektronics
Pavel Curtis Xerox
Steve Haflich Franz
Dieter Kolb Siemans
Sandra Loosemore E&S/Utah
Rob McLaughlin CMU
Jeff Peck SUN
Jonathan Rees MIT
Dave Touretzky CMU
Discussed "need volunteer" issues. Bob Mathis will mail a ballot on closed
topics from clean-up committee. JonL White proposed we bring forward old
issues and reject or adopt them. Larry Mascinter will provide a list.
AREF-1D no comments or objections
GET-SETF-METHOD-ENVIRONMENT no comments or objections
KEYWORD-ARGUMENT-NAME-PACKAGE no comments or objections
PATHNAME-STREAM some comments no objections
DO-SYMBOLS Jonl White suggested DO-PRESENT-SYMBOLS
and will send mail to Larry Masinter.
DECLARE-MACROS Goldhill objected on grounds of incompatible
changes. A long discussion ensued.
10:38am - Break
Item 17: Further discussions on cleanup and drafting, continued.
PATHNAME-SUBDIRECTORY-LIST
Item 22, 24: Planning Relative to Other Technical Issues,
Review Action Item Assignments, Bob Mathis
ISO letter. Committee chairman, people on committees, net names. A motion
was made to thank Lucid, Goldhill and Hewlet Packard. The motion was
approved and Bob Mathis will send thank you letters.
Item 23: Future Meetings, Bob Mathis
Discussion of length and format of future meetings. It was voted that we
would have a 5 day meeting in March 1988 and a tentative date was set for
March 21 through March 25. The first 2 days will be set aside for
subcommittee meetings, the next 2 days will be used for the meeting, and the
last day will be set aside for subcommittee meetings. A reminder that all
proposals should be in the hands of the committee 2 weeks prior to the
meeting. That means mailing 4 - 5 weeks before the actual meeting.
The following meetings are tentatively scheduled June 13 - 17 on the east
coast, September 26 - 30 central or west coast and January 9 - 13 1989 in
Hawaii.
(NOTE: Although March 21 - 25 was discussed as a possible meeting date,
March 14 - 18 has really been set. )
Item 20: Planning for ISO participation, Bob Mathis
Discussion on who should/could go to ISO in February.
Item 25: Adjournment 12:00, Bob Mathis
Jan Zubkoff
Acting Sectretary
∂02-Dec-87 1652 emma@russell.stanford.edu CSLI Calendar, December 3, 3:9
Received: from RUSSELL.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 87 16:52:08 PST
Received: by russell.stanford.edu (3.2/4.7); Wed, 2 Dec 87 16:12:17 PST
Date: Wed, 2 Dec 87 16:12:17 PST
From: emma@russell.stanford.edu (Emma Pease)
To: friends@russell.stanford.edu
Subject: CSLI Calendar, December 3, 3:9
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
3 December 1987 Stanford Vol. 3, No. 9
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 3 December 1987
12 noon TINLunch
Ventura Hall No TINLunch
Conference Room
2:15 p.m. CSLI Seminar
Room G-19 Cancelled
Redwood Hall
3:30 p.m. Tea
Ventura Hall
4:15 p.m. CSLI Colloquium
Ventura Hall Computerized Visual Communication for Aphasics
Trailer Classroom or Linguistics in Thought and Action
Michael Weinrich and Dick Steele
Department of Neurology
Stanford University School of Medicine
Abstract in the last Calendar
--------------
CSLI ACTIVITIES FOR THURSDAY, 10 December 1987
12 noon TINLunch
Ventura Hall No TINLunch
Conference Room
2:15 p.m. CSLI Seminar
Room G-19 FOG and Related Activities
Redwood Hall Hans Uszkoreit
3:30 p.m. Tea
Ventura Hall
--------------
ANNOUNCEMENT
Please note that the CSLI Seminar for this Thursday, 3 December, has
been cancelled.
--------------
∂02-Dec-87 2154 REGES@Score.Stanford.EDU Reappointment of Roy Jones
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 87 21:54:53 PST
Date: Wed 2 Dec 87 21:49:17-PST
From: Stuart Reges <REGES@Score.Stanford.EDU>
Subject: Reappointment of Roy Jones
To: ac@Score.Stanford.EDU
Office: CS-TAC 22, 723-9798
Message-ID: <12355434593.13.REGES@Score.Stanford.EDU>
We need to make a decision about whether or not to reappoint Roy Jones as a
lecturer in CS. University policy dictates that we appoint him for no less
than a three-year term (9/1/88 through 8/31/91). He is in his second year with
us and seems to be doing quite well. He teaches CS105A, our intro course for
humanities students, and has the distinction of being the first instructor in
years to receive good evaluations. CS105A is now one of our more popular
courses. He has also taught CS106 and CS223 and has received sometimes median,
but usually significantly higher than median, teaching evaluations. He has
served on the undergrad and MS committees and has advised both undergrads and
MS students. I think that Roy is making a valuable contribution to the
department and that he will continue to do so.
Nils and I are recommending to reappoint him, but we didn't want to do so
without consulting the faculty. If I receive no objection by next Monday, we
will go ahead with the reappointment. I am happy to provide more details to
anyone who is interested.
p.s. Please be careful not to comment on this to the FACULTY@SCORE list,
because Roy is on that list. If you want to send a note to the faculty
about this subject, please send it to AC@SCORE.
-------
∂03-Dec-87 1004 @Score.Stanford.EDU:cheriton@pescadero.stanford.edu Re: Reappointment of Roy Jones
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Dec 87 10:04:15 PST
Received: from pescadero.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 3 Dec 87 09:55:46-PST
Received: by pescadero.stanford.edu; Thu, 3 Dec 87 10:00:06 PST
Date: Thu, 3 Dec 87 10:00:06 PST
From: David Cheriton <cheriton@pescadero.stanford.edu>
To: REGES@score.stanford.edu, ac@score.stanford.edu
Subject: Re: Reappointment of Roy Jones
It was my understanding that, based on a recent facultyy decision, that these
matters would be voted on at a faculty meeting. Is there some reason
we cannot accomplish this at the Fac. meeting on Jan. 5th?
I continue to believe that these appointmnets are too important to relegate
to the "if there are no objections" style of defaulting.
I, for one, would like to see a resume which includes his teaching
and committee work and a few respresentative teaching evals.
Am I being unreasonable again?
∂03-Dec-87 1057 @Score.Stanford.EDU:FEIGENBAUM@SUMEX-AIM.Stanford.EDU Re: Reappointment of Roy Jones
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Dec 87 10:56:58 PST
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 3 Dec 87 10:51:25-PST
Date: Thu, 3 Dec 87 10:55:10 PST
From: Edward Feigenbaum <FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
Subject: Re: Reappointment of Roy Jones
To: cheriton@pescadero.stanford.edu, REGES@score.stanford.edu,
ac@score.stanford.edu
In-Reply-To: Message from "David Cheriton <cheriton@pescadero.stanford.edu>" of Thu, 3 Dec 87 10:05:22 PST
Message-ID: <12355577660.66.FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
I think David is being reasonable in his request.
I don't know Roy personally, but I heard from Stuart that he is a good teacher.
I also remember hearing (though I may be wrong) that Roy's formal training
is at the Bachelor's level. Perhaps that's fine for courses at the CS105
intro levels. But for the CS123 course (which is an area course, namely AI
area) I think it is inappropriate. If we would have trouble staffing it from
within (which I doubt) there are numerous AI stars in the area who might be
induced to teach it.
Again, I don't want to be negative about Roy, because I don't know him and
dont have any negative evidence. I just want to do what is right for the
students.
Ed
-------
∂03-Dec-87 1144 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Reappointment of Roy Jones
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Dec 87 11:44:17 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 3 Dec 87 11:38:12-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA05485; Thu, 3 Dec 87 11:43:08 PST
Date: Thu, 3 Dec 87 11:43:08 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8712031943.AA05485@Tenaya.stanford.edu>
To: cheriton@pescadero.stanford.edu
Cc: REGES@score.stanford.edu, ac@score.stanford.edu
In-Reply-To: David Cheriton's message of Thu, 3 Dec 87 10:00:06 PST <8712031806.AA05388@Tenaya.stanford.edu>
Subject: Reappointment of Roy Jones
Stuart, I know you are under some time pressure on the Roy Jones
re-appointment; yet if there are faculty members who would like to
see the matter discussed, voted on, etc., I think the spirit of our
new policy is to enable that. (We can interpret Stuart's msg saying
that "if there are no objections ...." to be a query asking if we
can get by without a formal discussion/vote. But since David brings
the point up, perhaps we ought to have some discussion.) If we are
operating under a deadline wrt to Roy, perhaps we ought to have a special
faculty meeting sometime next week---after distributing material
about Roy's performance. -Nils
∂03-Dec-87 1311 @Score.Stanford.EDU:tanya@mojave.stanford.edu
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Dec 87 13:11:02 PST
Received: from mojave.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 3 Dec 87 13:03:36-PST
Received: by mojave.stanford.edu; Thu, 3 Dec 87 13:05:04 PST
Date: 3 Dec 1987 1305-PST (Thursday)
From: Tanya Walker <tanya@mojave.stanford.edu>
To: faculty@score.stanford.edu, ksl@sumex-aim.stanford.edu
Cc:
Subject:
COURSE ANNOUNCEMENT
Winter Quarter 1987-1988
PARALLEL COMPUTER ARCHITECTURES AND PROGRAMMING
Anoop Gupta and Jonathan Rose
Course Number: CS411
Time: TTh 11:00-12:15
Parallel computers play a key role in the design of high performance systems.
An understanding of the architectural and programming issues involved is a
prerequisite for pursuing research in this area as well as being able to make
effective use of existing parallel computers. This course should be of
interest to students who would like to do research in the design of parallel
computer architectures and to those who wish to learn how to program them.
The course will consist of three parts. The first part will focus on parallel
computer hardware and will cover general principles and the design space. We
will survey research and commercial parallel machines including shared-memory,
message-passing, dataflow, systolic, and massively parallel architectures. The
second part will focus on parallel programming models and languages. Topics
will include a brief survey of parallel programming models and languages, and
study of techniques for communication and synchronization. The third part of
the course will focus on applications. Implementation trade-offs dealing with
granularity, communication, data access patterns, and load balancing will be
studied using example programs corresponding to real applications. The course
will include a set of programming assignments to be done on one or more
commercial multiprocessors.
As prerequisites, students should have a good background in computer
architecture (CS212/EE282), reasonable programming experience, and some
familiarity with operating systems. If you have any questions, feel free to
call Anoop Gupta at x5-3716 or send mail to ag@pepper.
∂03-Dec-87 1552 REGES@Score.Stanford.EDU Roy Jones
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Dec 87 15:52:35 PST
Date: Thu 3 Dec 87 15:44:22-PST
From: Stuart Reges <REGES@Score.Stanford.EDU>
Subject: Roy Jones
To: ac@Score.Stanford.EDU
Office: CS-TAC 22, 723-9798
Message-ID: <12355630307.40.REGES@Score.Stanford.EDU>
The University states that we must make reappointment decisions by December
1st to give people enough warning. If we delay until January, and we decide
not to reappoint, then Roy could demand that we keep him on anyway because
we didn't give him sufficient warning.
I will put together a packet of info about Roy and have it distributed by
Monday. We have Grey Tuesday next Tuesday starting at 2:30. Nils and Mike
Genesereth are both out of town, but I'll be a bit presumptuous and assume that
I can grab time at either the beginning or end of the meeting for this issue.
-------
∂03-Dec-87 1607 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com Next Monday's PLANLUNCH -- Marcel Schoppers
Received: from WARBUCKS.AI.SRI.COM by SAIL.STANFORD.EDU with TCP; 3 Dec 87 16:06:47 PST
Received: from venice by WARBUCKS.AI.SRI.COM via SMTP with TCP; Thu,
3 Dec 87 15:58:50-PST
Received: by venice (3.2/4.16) id AA13034 for
planlunch@warbucks.ai.sri.com; Thu, 3 Dec 87 16:03:52 PST
Date: Thu, 3 Dec 87 16:03:52 PST
From: Amy Lansky <lansky@venice.ai.sri.com>
Message-Id: <8712040003.AA13034@venice>
To: planlunch@warbucks.ai.sri.com
Subject: Next Monday's PLANLUNCH -- Marcel Schoppers
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
COMPOSING AND DECOMPOSING UNIVERSAL PLANS
Marcel Schoppers
Advanced Decision Systems (MARCEL@ADS.ARPA)
11:00 AM, MONDAY, December 7
SRI International, Building E, Room EJ228
``Universal plans'' are representations for robot behavior; they are
unique in being both highly reactive and automatically synthesized. As
a consequence of this plan representation, subplans have conditional
effects, and hence there are conditional goal conflicts. When block
promotion (= subplan concatenation) cannot remove an interaction, I
resort not to individual promotion (= subplan interleaving) but to
confinement (falsifying preconditions of the interaction). With
individual promotion out of the way, planning is a fundamentally
different problem: plan structure directly reflects goal structure,
plans can be conveniently composed from subplans, and each goal
conflict needs to be resolved only once during the lifetime of the
problem domain. Conflict analysis is computationally expensive,
however, and interactions may be more easily observed at execution
time than predicted at planning time.
All conflict elimination decisions can be cached as annotated
operators. Hence it is possible to throw away a universal plan, later
reconstructing it from its component operators without doing any
planning. Indeed, an algorithm resembling backchaining mindlessly
reassembles just enough of a universal plan to select an action that
is helpful in the current world state. Since the selected action is
both a situated response and part of a plan, recent rhetoric about
situated action as *opposed* to planning is defeated.
∂04-Dec-87 0934 TAJNAI@Score.Stanford.EDU Unveiling of the new CSD Brochure
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Dec 87 09:34:25 PST
Date: Fri 4 Dec 87 09:24:45-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Unveiling of the new CSD Brochure
To: faculty@Score.Stanford.EDU, staff@Score.Stanford.EDU
Message-ID: <12355823344.15.TAJNAI@Score.Stanford.EDU>
Nils Nilsson is treating us to Domaine Chandon Brut Champagne,
Monday afternoon 4:30, 3rd floor Jacks, to celebrate the
new and first ever CSD brochure. I feel like it's a
christening! So come help us celebrate.
Carolyn
-------
∂04-Dec-87 1040 @CSLI.Stanford.EDU:barwise@alan.stanford.edu Summer internships
Received: from RUSSELL.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Dec 87 10:39:58 PST
Received: from CSLI.Stanford.EDU by russell.stanford.edu (3.2/4.7); Fri, 4 Dec 87 10:32:35 PST
Received: from alan.stanford.edu by CSLI.Stanford.EDU with TCP; Fri 4 Dec 87 10:35:54-PST
Received: from localhost by alan.stanford.edu (3.2/4.7); Fri, 4 Dec 87 10:42:28 PST
To: ssp-students@alan.stanford.edu
Cc: ssp-faculty@alan.stanford.edu
Subject: Summer internships
Date: Fri, 04 Dec 87 10:42:27 PST
From: barwise@alan.stanford.edu
CSLI is going to find 6 summer internships this coming summer, so that
SSP students can work on projects with faculty and consulting faculty.
There will be two internships at each of Stanford, SRI International
AI Center, and in the Intillent System Lab at Xerox PARC.
Deadlines for and details about application proceedures will be
announced later. However, applications where concrete plans for
projects with faculty or consulting faculty will clearly be more
favorably received than applications where the student has no such
plans, other things being equal.
∂04-Dec-87 2202 OKUNO@SUMEX-AIM.Stanford.EDU My E-mail address in Japan
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Dec 87 22:01:55 PST
Date: Fri, 4 Dec 87 22:00:45 PST
From: Hiroshi "Gitchang" Okuno <Okuno@SUMEX-AIM.Stanford.EDU>
Subject: My E-mail address in Japan
To: aap@SUMEX-AIM.Stanford.EDU
cc: crispin@SUMEX-AIM.Stanford.EDU
Organization: Knowledge Systems Laboratory, CSD, Stanford University
Group: Heuristic Programming Project
Project: Advanced Architectures Project
Address: 701 Welch Road, Building C, Palo Alto, CA 94304-1703
Phone: +1 (415)725-4854
Message-ID: <12355960969.15.OKUNO@SUMEX-AIM.Stanford.EDU>
I'm back from Colorado Springs and will leave for Japan tommorow morning.
You can reach me in Japan by E-mail. My address is
from sumex,
okuno@ntt-20 (a direct link between sumex and ntt-20)
okuno@ntt-20.ntt.jp (a direct link)
okuno@ntt-20.ntt.jp.#internet (via CSNET)
and from other sites
okuno%ntt-20.ntt.jp@relay.cs.net
Thanks,
- Gitchang -
-------
∂06-Dec-87 1439 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talk
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Dec 87 14:39:44 PST
Date: Sun 6 Dec 87 14:31:31-PST
From: Anil R. Gangolli <GANGOLLI@Sushi.Stanford.EDU>
Subject: Upcoming AFLB Talk
To: aflb.all@Sushi.Stanford.EDU
Office Phone: (415) 723-3605
Message-ID: <12356403476.28.GANGOLLI@Sushi.Stanford.EDU>
PLEASE NOTE:
* This is the last talk of the quarter. AFLB will
resume on the 7th of January, 1988.
THIS WEEK'S TALK:
10-December-87: John Canny (Berkeley)
Robot Motion Planning and Real Geometry
The goal of this work is to come up with fast motion planning
algorithms, in both a formal and practical sense, which have some kind
of performance guarantee. The main result is for the generalized
movers' problem, which is motion planning for an arbitrary robot with
kinematic constraints only. I will present an algorithm for this
problem called the ``roadmap algorithm'' which equals or improves the
bounds of most of the special purpose exact algorithms that have
appeared over the last few years. The algorithm also involves lower
constants than the others and is a plausible candidate for
implementation. I will also consider motion planning with dynamic
constraints, minimal motion planning, and motion planning with
uncertainty, and give new lower bounds for these problems. The lower
bound results are joint work with John Reif of Duke university.
The roadmap algorithm is in effect a decision algorithm for the first
order existential theory of real numbers. It makes use of results in
singularity theory, in particular the notion of stratified sets, which
provide a very natural and efficient way to represent geometric
objects. It also uses a new (actually very old but obscure) algebraic
tool called the multivariate resultant. This latter tool gives a fast
parallel method for solving systems of equations, and should give
improvements in algorithms for inverse kinematics, CSG modeling, and
geometric theorem proving.
*** Time and Place: 12:30pm, Thurs., Dec. 10, MJH (Bldg 460), Room 352 ***
-------
∂06-Dec-87 2303 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com REMINDER -- Monday Planlunch -- Marcel Schoppers
Received: from WARBUCKS.AI.SRI.COM by SAIL.STANFORD.EDU with TCP; 6 Dec 87 23:03:51 PST
Received: from venice by WARBUCKS.AI.SRI.COM via SMTP with TCP; Sun,
6 Dec 87 22:55:37-PST
Received: by venice (3.2/4.16) id AA00311 for
planlunch_reminder@WARBUCKS.ai.sri.com; Sun, 6 Dec 87 23:00:08 PST
Date: Sun 6 Dec 87 23:00:06-PST
From: Amy Lansky <LANSKY@venice.ai.sri.com>
Subject: REMINDER -- Monday Planlunch -- Marcel Schoppers
To: planlunch_reminder@WARBUCKS.ai.sri.com
Message-Id: <565858806.0.LANSKY@VENICE.ARPA>
Mail-System-Version: <SUN-MM(213)+TOPSLIB(128)@VENICE.ARPA>
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
COMPOSING AND DECOMPOSING UNIVERSAL PLANS
Marcel Schoppers
Advanced Decision Systems (MARCEL@ADS.ARPA)
11:00 AM, MONDAY, December 7
SRI International, Building E, Room EJ228
``Universal plans'' are representations for robot behavior; they are
unique in being both highly reactive and automatically synthesized. As
a consequence of this plan representation, subplans have conditional
effects, and hence there are conditional goal conflicts. When block
promotion (= subplan concatenation) cannot remove an interaction, I
resort not to individual promotion (= subplan interleaving) but to
confinement (falsifying preconditions of the interaction). With
individual promotion out of the way, planning is a fundamentally
different problem: plan structure directly reflects goal structure,
plans can be conveniently composed from subplans, and each goal
conflict needs to be resolved only once during the lifetime of the
problem domain. Conflict analysis is computationally expensive,
however, and interactions may be more easily observed at execution
time than predicted at planning time.
All conflict elimination decisions can be cached as annotated
operators. Hence it is possible to throw away a universal plan, later
reconstructing it from its component operators without doing any
planning. Indeed, an algorithm resembling backchaining mindlessly
reassembles just enough of a universal plan to select an action that
is helpful in the current world state. Since the selected action is
both a situated response and part of a plan, recent rhetoric about
situated action as *opposed* to planning is defeated.
-------
∂07-Dec-87 0908 GENESERETH@Score.Stanford.EDU Re: Reappointment of Roy Jones
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Dec 87 09:08:46 PST
Date: Mon 7 Dec 87 09:03:02-PST
From: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Subject: Re: Reappointment of Roy Jones
To: cheriton@Pescadero.Stanford.EDU
cc: REGES@Score.Stanford.EDU, ac@Score.Stanford.EDU
In-Reply-To: Message from "David Cheriton <cheriton@pescadero.stanford.edu>" of Thu 3 Dec 87 09:56:04-PST
Message-ID: <12356605821.32.GENESERETH@Score.Stanford.EDU>
I agree with David.
mrg
-------
∂07-Dec-87 0956 RICHARDSON@Score.Stanford.EDU Lunch
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Dec 87 09:56:37 PST
Date: Mon 7 Dec 87 09:50:02-PST
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: Lunch
To: faculty@Score.Stanford.EDU
Message-ID: <12356614378.10.RICHARDSON@Score.Stanford.EDU>
Lunch tomorrow with general discussion in MJH 146 at 12:15.
-------
∂07-Dec-87 1210 ullman@navajo.stanford.edu paper received
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Dec 87 12:10:47 PST
Received: by navajo.stanford.edu; Mon, 7 Dec 87 12:03:59 PST
Date: Mon, 7 Dec 87 12:03:59 PST
From: Jeff Ullman <ullman@navajo.stanford.edu>
Subject: paper received
To: nail@navajo.stanford.edu
"An extended relational query language for knowledgebase support"
J. Biskup, U. Raesch, H. Steifeling, Hochschule Hildesheim, W. Germany.
Proposes graph-theoretic primitives to augment relational algebra,
so you can do transitive closure, e.g.
---jdu
PS: Is "knowledgebase" becoming one word the way "database" did?
∂07-Dec-87 2316 GENESERETH@Score.Stanford.EDU Grey Tuesday
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Dec 87 23:16:25 PST
Date: Mon 7 Dec 87 23:10:45-PST
From: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Subject: Grey Tuesday
To: ac@Score.Stanford.EDU
Message-ID: <12356760145.13.GENESERETH@Score.Stanford.EDU>
Folks,
Please remember that our Grey Tuesday meeting is at 2:30 on December 8th
in 252. I have been asked by sevreal people to try to keep the meeting
as short as possible, and I myself need to need to leave shortly after
4 to catch a plane. Therefore, I would like to (1) get started exactly on
time and (2) keep the discussion to the 35 or so students who need attention
and (3) minimize discussion of new policy in favor of discussion of
conformity with established policy. Please try to be there on time;
and,i in the unlikely event that any of you cannot make the meeting,
please send a message about your students to either Sharon Hemenway
or myself. Thanks.
mrg
-------
∂07-Dec-87 2331 LOGMTC-request 12/10, 1pm, MJH301: Talk on Automated Induction proofs.
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Dec 87 23:31:15 PST
Date: Mon 7 Dec 87 23:25:43-PST
From: Natarajan Shankar <SHANKAR@Score.Stanford.EDU>
Subject: 12/10, 1pm, MJH301: Talk on Automated Induction proofs.
To: csd@Score.Stanford.EDU, logic@alan.Stanford.EDU, logmtc@Sail.Stanford.EDU
Message-ID: <12356762869.9.SHANKAR@Score.Stanford.EDU>
Title: A rational reconstruction of Boyer and Moore's algorithm for
the construction of induction schemata.
Speaker: Andrew Stevens (University of Edinburgh)
Time: Thur. Dec. 10, 1 PM.
Place: MJH 301
Abstract
--------
We present a rational reconstruction of Boyer and Moore's
technique for the NuPRL proof development environment.
This reconstruction tackles these main issues:
o providing a coherent meta-theoretic framework for the algorithms'
operation.
o The Adaptations to the algorithm necessary to support it's application
in logics other than that of Boyer and Moore's theorem prover.
In addition we present several significant enhancements to the original,
and fix some bugs present in the system as described in [1].
We conclude with an analysis of two fundamental flaws in Boyer and
Moore's approach and propose an alternative approach that tackles
these problems this is better suited for further development.
References
----------
[1] R.S. Boyer and J.S.Moore - A Computational Logic, Academic Press 1979.
ACM monograph series.
-------
∂08-Dec-87 0857 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Sequences, Combinatorics, Compression,
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 87 08:57:33 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 8 Dec 87 08:50:44-PST
Received: by lindy.stanford.edu; Tue, 8 Dec 87 08:53:20 PST
Received: by Forsythe.Stanford.EDU; Tue, 8 Dec 87 08:54:49 PST
Received: by NDSUVM1 (Mailer X1.24) id 8573; Tue, 08 Dec 87 09:09:29 CST
Date: 8 Dec 1987 10:04:42-EST (Tuesday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Zvi Galil <GALIL%CS.COLUMBIA.EDU@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Zvi Galil <GALIL%CS.COLUMBIA.EDU@forsythe.stanford.edu>
Subject: Sequences, Combinatorics, Compression,
Security and Transmission Call f
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
-------------------------------------------------------------------------
CALL FOR PAPERS
SEQUENCES
COMBINATORICS, COMPRESSION,
SECURITY AND TRANSMISSION
Amalfi Coast, Salerno, Italy, June 6--10, 1988
Authors are invited to submit papers describing new advances, applications
and ideas related to combinatorics, compression, security and transmission
of sequences.
Program Committee:
Bella Bose (OSU, USA),
Renato M. Capocelli (Chairman, Univ. Salerno, Italy),
Shimon Even (Technion, Israel),
Zvi Galil (Columbia Univ., USA and Tel-Aviv Univ., Israel),
Abraham Lempel (Technion, Israel),
Antonio Restivo (Univ. Palermo , Italy)
A preliminary list of speakers includes:
M.D. Atkinson (Carleton Univ., Canada),
F. Blanchard (Univ. Paris VI, France)
B. Bose (OSU, USA),
M. Blum (Berkley, USA),
A. Blumer (Tufts Univ., USA),
G.D. Cohen (E'cole Nat. Sup. Tel., France),
A. De Luca (Rome, Italy),
P. Erdo"s (Hungarian Acad. of Sci., Hungary),
S. Even (Technion, Israel),
Z. Galil (Columbia Univ., USA and Tel-Aviv Univ. Israel)
O. Goldreich (Technion , Israel),
T. Head (Univ. of Alaska, USA),
J. Ko"rner (Hungarian Acad. of Sci., Hungary),
A. Lempel (Technion, Israel),
M. Luby (Univ. of Toronto, Canada),
F. Luccio (Univ. Pisa, Italy),
D. Perrin (Univ. Paris VII, France),
M. Rabin (Harvard, USA and Hebrew Univ. Israel),
A. Restivo (Univ. Palermo, Italy),
J. Rissanen (IBM, USA),
W. Rytter (Warsaw Univ., Poland),
P. Siegel (IBM, USA),
J.A. Storer (Brandeis Univ., USA),
M. Tompa (IBM USA),
M.N. Wegman (IBM, USA),
V.K. Wei (Bell Communication Center, USA),
J. Ziv (Technion, Israel).
Intended contributors are invited to submit five copies of a detailed
abstract or a draft paper to:
Prof. Renato M. Capocelli
Dipartimento di Informatica ed Applicazioni, Universita' di Salerno
I-84100 Salerno, ITALY
[uucp address: mcvax!inria!udsab!rmc, tel. (89) 878299 ext. 327]
by March 15, 1988. Notification of acceptance follows by April
15, 1988.
For further information contact the above or:
Prof. Filomena de Santis
Dipartimento di Informatica ed Applicazioni, Universita' di Salerno
I-84100 Salerno, ITALY
[uucp address: mcvax!inria!udsab!fds, tel. (89) 878299 ext. 332]
To mantain a workshop atmosphere there will be a limited number of paper
presented.
Selected papers will be included in the Proceedings of the Workshop to be
published by an international publishing company.
∂08-Dec-87 1002 STAGER@Score.Stanford.EDU End Quarter Grade sheets
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 87 10:02:06 PST
Date: Tue 8 Dec 87 09:55:32-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: End Quarter Grade sheets
To: instructors@Score.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12356877524.21.STAGER@Score.Stanford.EDU>
The End Quarter Grade Sheets have arrived. The majority of them will go out
via courier today. If you haven't received your grade sheets by Friday
(December 11) please give me a call at 3-6094.
Grade sheets should be returned either to my office in CS-TAC, or placed
in the CS-TAC box at MJH for pickup by our courier. Please have them
back to me no later than noon, Monday December 21.
Thanks again for your cooperation.
Claire
-------
∂08-Dec-87 1129 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Proposed rights income policy change
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 87 11:28:51 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 8 Dec 87 11:22:12-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA02597; Tue, 8 Dec 87 11:27:26 PST
Date: Tue, 8 Dec 87 11:27:26 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8712081927.AA02597@Tenaya.stanford.edu>
To: faculty@score
Cc: nilsson
Subject: Proposed rights income policy change
Proposed New Policy Regarding Rights Income
When a Stanford faculty or staff member invents or copyrights
something owned by the University, the University shares the income
from such rights according to the following formula: 1/3 to
individual's unrestricted funds acct., 1/3 to individual's department,
1/3 to individual's school. According to current CSD policy (ref: CSD
faculty mtg of 9/30/80), if the individual assigns his/her unrestricted
funds account income share to a research project or to a research
group, then the Department also assigns its share to that project or
group. I think this policy acts against the interest of the
commonweal, and I am going to propose at the January 5, 1988 general
faculty meeting that it be abolished and replaced by a policy in which
the Department retains its share of the income regardless of what the
individual might do with his/her share. The purpose of this memo is
to let people know in advance that I am going to make this proposal,
to argue for it, and to give others a chance to discuss it via e-mail
before the meeting if they would like.
Here are my reasons:
The tradition at Stanford (as constrasted with that of some other
leading universities) places the department in a relatively weakened
financial position with respect to the research projects and PIs.
There are very few sources of funds available to the department to use
for the benefit of all research projects generally. The research
projects do not have a tradition of banding together in a
department-wide way to provide for department-wide needs that benefit
research. (There are some exceptions; setting up CSD-CF to provide
computer services is one.) One expense that the Department is now
subsidizing is the support of first-year PhD students. The department
largely pays these stipends without help from the research projects;
yet the research projects benefit by having these PhD students do
research for them when they are ready. Another expense is the
subsidization of new faculty member research support and equipment
(for example Sun workstations) while new faculty are getting
themselves established and while they are writing their own research
proposals.
We have to find a way to deal with these department-wide needs while
still retaining the individual, entrepreneurial Stanford tradition.
One possibility is to insist that people build into their research
proposals an expense item for generalized support of first-year PhD
students (CMU must do something like this; at least the "pot" seems to
be adequate for the general department-wide CMU research needs). In
any case, we need to stem the flow of funds available to the
department generally into specific research projects or into
less-than-department-wide research groupings. In light of the above,
we need instead to find ways to cause a little flow in the other
direction. Therefore, when the Department does have available some
funds (such as the ones coming to it from rights), it does not make
sense for the Department to re-assign these automatically to research
projects.
-Nils
∂08-Dec-87 1253 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Complexity of optimal addition chains
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 87 12:53:30 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 8 Dec 87 12:44:27-PST
Received: by lindy.stanford.edu; Tue, 8 Dec 87 12:47:25 PST
Received: by Forsythe.Stanford.EDU; Tue, 8 Dec 87 12:49:03 PST
Received: by NDSUVM1 (Mailer X1.24) id 3533; Tue, 08 Dec 87 14:29:02 CST
Date: 8 Dec 1987 15:18:48-EST (Tuesday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Victor S. Miller" <VICTOR%YKTVMZ.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Victor S. Miller" <VICTOR%YKTVMZ.BITNET@forsythe.stanford.edu>
Subject: Complexity of optimal addition chains
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
Given a positive integer n, written in unary, is it known if finding the
least cost addition chain for n is in P?
∂08-Dec-87 1327 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Optimal cost addition chains
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 87 13:26:56 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 8 Dec 87 13:18:14-PST
Received: by lindy.stanford.edu; Tue, 8 Dec 87 13:21:10 PST
Received: by Forsythe.Stanford.EDU; Tue, 8 Dec 87 13:22:30 PST
Received: by NDSUVM1 (Mailer X1.24) id 4168; Tue, 08 Dec 87 14:36:13 CST
Date: 8 Dec 1987 15:23:37-EST (Tuesday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Victor S. Miller" <VICTOR%YKTVMZ.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Victor S. Miller" <VICTOR%YKTVMZ.BITNET@forsythe.stanford.edu>
Subject: Optimal cost addition chains
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
Boy am I dense! After sending out my request I realized that it is
true (almost trivially): the optimal cost chain is of length < 2*lg n,
so just enumerate them all. Of course, a more interesting problem arises
if n is written in binary, does anyone know anything about that ( other
than what's in Knuth v 2)? In particular, is it NP complete (maybe)?
∂08-Dec-87 1932 LOGMTC-request Wednesday seminar: Dynamic Types
Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 8 Dec 87 19:32:35 PST
Received: from sun.Sun.COM ([192.9.2.3]) by Sun.COM (4.0/SMI-3.2)
id AA04317; Tue, 8 Dec 87 19:32:07 PST
Received: from coraki.UUCP by sun.Sun.COM (4.0/SMI-4.0)
id AA16096; Tue, 8 Dec 87 19:32:41 PST
Received: by coraki.uucp (3.2/SMI-1.2)
id AA17798; Tue, 8 Dec 87 19:29:08 PST
Date: Tue, 8 Dec 87 19:29:08 PST
From: coraki!pratt@Sun.COM (Vaughan Pratt)
Message-Id: <8712090329.AA17798@coraki.uucp>
To: conmod@navajo.stanford.edu
Subject: Wednesday seminar: Dynamic Types
Cc: friends@csli.stanford.edu, logmtc@sail.stanford.edu
Speaker: Vaughan Pratt
Title: Arithmetic of Dynamic Types
Location: MJ301
Time: 10:00-12:00, Wednesday Dec. 9
Abstract:
I will present a simplified and strengthened definition of "dynamic
type." The basic notion of a dynamic type as an edge-labeled and
vertex-labeled graph with additional categorical structure remains
unchanged. The difference is the elimination of the category Set from
the definition. Besides being more in tune with modern category
theory, the new definition has the practical effect of permitting new
types to be named, the most elementary of which is 2|>2, the dynamic
type of order ideals. Applications of 2|>2 include the definition of
the reals and the proof of Stone's theorem. The arithmetic of order
ideals is obtained by exactly the same process as for the arithmetic of
Set = 1|>1, Cat = (1|>1)|>1, Prom = 2|>(1|>1) (whose arithmetic
constitutes the concurrent programming language SSL), etc. I will
conclude with a discussion of the relevance of dynamic types to
Birkhoff's vision of generalized arithmetic.
-v
∂09-Dec-87 0843 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #95
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Dec 87 08:43:09 PST
Date: Wed 9 Dec 1987 05:47-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #95
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Wednesday, 9 Dec 1987 Volume 5 : Issue 95
Today's Topics:
Query - termCompare/3,
Theory - Impediments,
Puzzle - Challenge
----------------------------------------------------------------------
Date: 3 Dec 87 06:18:39 GMT
From: ubc-vision!alberta!calgary!spooner@beaver.cs.washington.edu
(David Spooner)
Subject: NU-Prolog termCompare/3.
Does anyone have any thoughts on why the goal:
?- termCompare(T, [a], [b]).
succeeds with:
T = =
This causes problems when generating sets of lists with solutions/3,
for example powerset/2.
Also, redefining termCompare/3 does not help. The anomaly became apparent
when using addElement/3 in the osets library.
?- Is there a problem with performing recursive term comparison based not
only on cardinality.
------------------------------
Date: Tue, 01 Dec 87 11:01:51 PST
From: narain%pluto@rand-unix.ARPA
Subject: Theoretical impediments
My note did mention that PA is decidable. Since Horn clauses are not,
it is plausible that the latter are richer than the former. This
argument can be made exact.
Every effectively computable function is definable in Horn clauses.
In particular, we can encode any decision procedure for PA as a set of
Horn clauses. Now the Fischer-Rabin result would apply to this set.
Hence, we have a problem in Horn clauses which takes super-exponential
time to solve.
-- Sanjai Narain
=============================================================================
------------------------------
Date: Mon, 7 Dec 87 11:05:40+0900
From: STANFORD Tick Evan <tick%icot.jp@RELAY.CS.NET>
Subject: PROGRAMMING CHALLENGE
To Whom it May Concern,
I am challenging everyone involved in the research of committed-choice
parallel logic programming languages to solve the following problem
using such a language. I am specifically interested in FGHC implementations.
The problem is the famous Puzzle Problem by F. Baskett, implemented in C,
FORTRAN, Pascal, Lisp, and Prolog. The Puzzle Problem is one of the most
popular performance benchmarks in the world. The problem is pack a 5x5x5
solid cube with 18 smaller pieces: 4x2x1 (13), 3x1x1 (3), 2x2x1 (1), and
2x2x2 (1). All 2005 solutions must be calculated and counted, but not
printed.
I have a serious concern that this problem is beyond the capacity of
current FGHC technology -- I myself have written a version of the program
but it runs out of memory or runs forever (more than four hours) on the
systems available at ICOT. I am not an expert programmer, however.
I therefore challege everyone in the programming
community to produce a better implementation that executes in a finite
amount of time. NOTE: the Prolog version I wrote runs very efficiently --
more efficiently than the Lisp version in the Gabriel Benchmarks. To show
that committed-choice languages REALLY deserve to be the foundation of
the 5th Generation Computer Project, I believe it is vital to solve this
problem. I believe the difficulty in solving this problem reflects more
than the immature technology. It reflects the inherent inefficiency of the
programming styles required by the language. I hope someone can disprove
this hypothesis.
Evan Tick
ICOT
tick%icot.jp@relay.cs.net
The following source program runs on Ueda's DEC-20 FGHC System...
-------------------------------- CUT HERE ------------------------------------
% Puzzle
% Evan Tick
% tick%icot.jp@relay.cs.net (ICOT)
% 11-26-87
%
% PROGRAM:
% This program runs under Ueda's DEC-20 FGHC system. To run, ?- ghc go.
% The puzzle problem requires packing 18 small pieces within a 5x5x5 cube.
% The pieces are: 4x2x1 (13), 3x1x1 (3), 2x2x1 (1), 2x2x2 (1). All 2005
% solutions must be found and counted, but not printed. This program
% runs out of CORE when solving the puzzle, therefore, a smaller puzzle
% (with only six solutions) is included for test purposes. The 5x5x5
% puzzle is also included, but in comments.
%
% NOTES:
% This is a semi-distributed version, i.e., the partial solution is
% represented solely by a group of piece processes. Each piece process
% can respond to the following commands:
% echo(I-O) --
% return D-list I-O of pieces
% check(Piece, Answer) --
% check Piece with the internal piece for consistency
% if consistent, return "yes", otherwise return "no"
%
% A select process first selects a Piece from the piece list.
% Two processes are spawned, connected by a merge box for routing
% later requests made by the children. The left child is a checkall
% and the right child is another select process. The main idea is
% that the checkall will find all solutions including the selected
% piece and the other child will find all solutions NOT including
% the selected piece.
%
% The Piece is of the form: orient(N,Olist), where N is the number of
% identically shaped pieces available, and Olist is a list of identifiers
% indicating the orientations of the shape. NOTE: the identifiers in
% all the Olist's of all the pieces are unique -- this trick is used
% to efficiently index during piece translation. The checkall attempts
% to spawn one checker process for each orientation of the selected piece.
% The piece is placed within each process, starting at the same origin.
% The translation from this origin is done with translate/4. If the
% translation produces an unsafe situation, i.e., the shape falls outside
% of the solid's boundaries, the checker process is not spawned.
% Each successfully spawned checker is connected serially with merge
% boxes.
%
% Calculation of the current origin (i.e., where to place the next
% selected piece) is made with two large lists (with a sum of 125 entries)
% representing the empty and filled squares of the solid. Each time
% a piece is selected, it is placed at the origin specified by the
% first element of the empty list. Subsequently, the empty list and
% full list must be updated to reflect this placement. This update
% is of course different for each orientation.
%
% Checking is done sequentially, by checking the closest piece (in
% the tree) and then the next piece, etc. If all pieces are ok,
% the check request arrives at a dummy piece ("special") at the
% top of the tree, which always sends a "yes" reply. If a piece
% is not ok, it sends a "no" reply itself. Thus checking is not
% done in parallel, like in the previous version, but work is
% actually saved by detecting early failure.
%
% This program cleans-up the pieces only AFTER all solutions have
% been found. This is accomplished by serializing the output with the
% top-level process. In addition, there is incremental garbage
% collection, implemented by short-circuiting the boxes. After
% incremental collection, at program completion, the only boxes remaining
% correspond to solution paths.
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
go :- true |
initial(Slist,Plist),
special(Snd),
select(Plist, Slist, [], Snd, X-[]),
outconv(X, Y, 0),
outstream(Y).
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% [Y|Ys] list of candidate pieces
% Empty list of empty squares
% NonC list of non-candidate pieces
% Snd communication streams to pieces above
% I-O answer stream
% in this case, choose last instance of this shape...
select([orient(M,L)|Ys], Empty, NonC, Snd, I-O):- M=:=1 |
append(Ys, NonC, Unused),
merge(SndL, SndR, Snd),
checkall(L, Unused, Empty, SndL, I-I1),
select(Ys, Empty, [orient(M,L)|NonC], SndR, I1-O).
% more than one instance of this shape exists...
select([orient(M,L)|Ys], Empty, NonC, Snd, I-O):- M=\=1 |
M1 := M-1,
append([orient(M1, L)|Ys], NonC, Unused),
merge(SndL, SndR, Snd),
checkall(L, Unused, Empty, SndL, I-I1),
select(Ys, Empty, [orient(M,L)|NonC], SndR, I1-O).
% no more shapes exist as candidates...
select([], _, [_|_], Snd, I-O):- true |
Snd = [], % remove unwanted box
I=O.
% all shapes have been selected --> solution has been found...
select([], _, [], Snd, I-O):- true |
% Snd = [echo(List-[])],
Snd = [], % remove box after you find solution
List = [dummy], % don't care about exact solution - just #
I = [List|O].
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% spawn checker process for each orientation in Piece
checkall([], _, _, Snd, I-O):- true |
Snd = [],
I=O.
checkall([O|Os], Unused, Empty, Snd, Answer) :- true |
Empty = [E|_],
translate(O, E, Piece),
check_piece(Piece, Status),
checkall1(Status, Os, Piece, O-E, Unused, Empty, Snd, Answer).
% translated piece falls outside of solid boundary...
checkall1(bad, Os, _, _, Unused, Empty, Snd, Answer) :- true |
checkall(Os, Unused, Empty, Snd, Answer).
% translated piece falls completely inside of solid...
checkall1(good, Os, Piece, Pretty, Unused, Empty, Snd, Answer) :- true |
remove(good, Piece, Empty, NewEmpty, Status),
checkall2(Status, Os, Piece, Pretty, Unused, Empty,
NewEmpty, Snd, Answer).
% translated piece falls inside a previously chosen piece...
checkall2(bad, Os, _, _, Unused, Empty, _, Snd, Answer) :- true |
checkall(Os, Unused, Empty, Snd, Answer).
% translated piece falls outside all previously chosen pieces...
checkall2(good, Os, Piece, Pretty, Unused, Empty, NewEmpty, Snd, I0-I2) :-
true |
merge(SndL, SndR, Snd),
checker(maybe, NewEmpty, Piece, Pretty, Unused, SndL, I0-I1),
checkall(Os, Unused, Empty, SndR, I1-I2).
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% checker process
% request check from piece above...
checker(maybe, Empty, Piece, Pretty, N, Snd, Answer):- true|
Snd = [check(Piece,Reply)|Snds],
checker(Reply, Empty, Piece, Pretty, N, Snds, Answer).
% special piece replied "yes", so Piece is ok...
checker(yes, Empty, Piece, Pretty, N, Snd, Answer) :- true |
piece(Snd1, Snd, Piece, Pretty),
select(N, Empty, [], Snd1, Answer).
% piece replied "no", so Piece is no good -- terminate process
checker(no, _, _, _, _, Snd, I-O) :- true |
Snd = [], % remove unwanted merge
I=O.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% piece processes
piece([], Snd, _, _) :- true |
Snd = [].
% echo back Piece
piece([echo(A-B)|Rcv], Snd, Piece, Pretty) :- true |
A = [Pretty|C], % append # to reply
Snd = [echo(C-B)|Snds], % send request up
piece(Rcv, Snds, Piece, Pretty).
piece([check(Piece1,Answer)|Rcv], Snd, Piece2, Pretty) :- true |
compare(Piece1, Piece2, Status),
piece2(Status, check(Piece1,Answer), Rcv, Snd, Piece2, Pretty).
% check succeeds...
piece2(yes, Request, Rcv, Snd, Piece, Pretty) :- true |
Snd = [Request|Snds],
piece(Rcv, Snds, Piece, Pretty).
% check fails...
piece2(no, check(_,Answer), Rcv, Snd, Piece, Pretty) :- true |
Answer = no,
piece(Rcv, Snd, Piece, Pretty).
% if list intersection is empty, Status=yes
% if list intersection is non-empty, Status=no
compare([], _, Status) :- true |
Status = yes.
compare([H|T], List, Status) :- true |
compare(List, H, T, List, Status).
compare([], _, T, List, Status) :- true |
compare(T, List, Status).
compare([Y|_], X, _, _, Status) :- X=Y |
Status = no.
compare([Y|Ys], X, T, List, Status) :- X \= Y |
compare(Ys, X, T, List, Status).
% special piece is dummy node at top-of-tree
special([]). % kill yourself
special([echo(A-B)|Rcv]) :- true |
A = B, % finish echo
special(Rcv).
special([check(_,Answer)|Rcv]) :- true |
Answer = yes, % always answer yes
special(Rcv).
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% remove(good, Vector, Empty, NewEmpty, Status)
% remove all elements in Vector from Empty
% return Status of removal: "good" if Vector was a subset of Empty
% "bad" if Vector contained elements not in Empty
remove(bad, _, _, _, Status) :- true |
Status = bad.
remove(good, [], Empty, NewEmpty, Status) :- true |
Status = good,
NewEmpty = Empty.
remove(good, [H|T], Empty, NewEmpty, Status) :- true |
remove2(Empty, H, NextEmpty, SubStatus),
remove(SubStatus, T, NextEmpty, NewEmpty, Status).
remove2([], _, Empty, Status) :- true |
Status = bad.
remove2([E|Es], H, Empty, Status) :- E=H |
Status = good,
Es = Empty.
remove2([E|Es], H, Empty, Status) :- E \= H |
Empty = [E|NewEmpty],
remove2(Es, H, NewEmpty, Status).
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% 4x2x1 (6 orientations)
translate(a, o(X,Y,Z), List) :- true |
X1 := X+1, X2 := X+2, X3 := X+3, Y1 := Y+1,
List = [o(X,Y, Z),o(X1,Y, Z),o(X2,Y, Z),o(X3,Y, Z),
o(X,Y1,Z),o(X1,Y1,Z),o(X2,Y1,Z),o(X3,Y1,Z)].
translate(b, o(X,Y,Z), List) :- true |
X1 := X+1, X2 := X+2, X3 := X+3, Z1 := Z+1,
List = [o(X,Y,Z), o(X1,Y,Z), o(X2,Y,Z), o(X3,Y,Z),
o(X,Y,Z1),o(X1,Y,Z1),o(X2,Y,Z1),o(X3,Y,Z1)].
translate(c, o(X,Y,Z), List) :- true |
Y1 := Y+1, Y2 := Y+2, Y3 := Y+3, Z1 := Z+1,
List = [o(X,Y,Z), o(X,Y1,Z), o(X,Y2,Z), o(X,Y3,Z),
o(X,Y,Z1),o(X,Y1,Z1),o(X,Y2,Z1),o(X,Y3,Z1)].
translate(d, o(X,Y,Z), List) :- true |
Y1 := Y+1, Y2 := Y+2, Y3 := Y+3, X1 := X+1,
List = [o(X, Y,Z),o(X, Y1,Z),o(X, Y2,Z),o(X, Y3,Z),
o(X1,Y,Z),o(X1,Y1,Z),o(X1,Y2,Z),o(X1,Y3,Z)].
translate(e, o(X,Y,Z), List) :- true |
Z1 := Z+1, Z2 := Z+2, Z3 := Z+3, X1 := X+1,
List = [o(X, Y,Z),o(X, Y,Z1),o(X, Y,Z2),o(X, Y,Z3),
o(X1,Y,Z),o(X1,Y,Z1),o(X1,Y,Z2),o(X1,Y,Z3)].
translate(f, o(X,Y,Z), List) :- true |
Z1 := Z+1, Z2 := Z+2, Z3 := Z+3, Y1 := Y+1,
List = [o(X,Y, Z),o(X,Y, Z1),o(X,Y, Z2),o(X,Y, Z3),
o(X,Y1,Z),o(X,Y1,Z1),o(X,Y1,Z2),o(X,Y1,Z3)].
% 3x1x1 (3 orientations)
translate(g, o(X,Y,Z), List) :- true |
X1 := X+1, X2 := X+2,
List = [o(X,Y,Z),o(X1,Y,Z),o(X2,Y,Z)].
translate(h, o(X,Y,Z), List) :- true |
Y1 := Y+1, Y2 := Y+2,
List = [o(X,Y,Z),o(X,Y1,Z),o(X,Y2,Z)].
translate(i, o(X,Y,Z), List) :- true |
Z1 := Z+1, Z2 := Z+2,
List = [o(X,Y,Z),o(X,Y,Z1),o(X,Y,Z2)].
% 2x2x1 (3 orientations)
translate(j, o(X,Y,Z), List) :- true |
X1 := X+1, Y1 := Y+1,
List = [o(X,Y,Z),o(X1,Y,Z),o(X,Y1,Z),o(X1,Y1,Z)].
translate(k, o(X,Y,Z), List) :- true |
X1 := X+1, Z1 := Z+1,
List = [o(X,Y,Z),o(X1,Y,Z),o(X,Y,Z1),o(X1,Y,Z1)].
translate(l, o(X,Y,Z), List) :- true |
Y1 := Y+1, Z1 := Z+1,
List = [o(X,Y,Z),o(X,Y1,Z),o(X,Y,Z1),o(X,Y1,Z1)].
% 2x2x2 (1 orientation)
translate(m, o(X,Y,Z), List) :- true |
X1 := X+1, Y1 := Y+1, Z1 := Z+1,
List = [o(X,Y,Z), o(X1,Y,Z), o(X,Y1,Z), o(X1,Y1,Z),
o(X,Y,Z1),o(X1,Y,Z1),o(X,Y1,Z1),o(X1,Y1,Z1)].
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% utilities...
append([A|X],Y,Z):- true |
Z=[A|Z1], append(X,Y,Z1).
append([], Y,Z):- true | Z=Y.
merge([], SndR, Snd) :- true | Snd = SndR.
merge(SndL, [], Snd) :- true | Snd = SndL.
merge([R|SndL], SndR, Snd) :- true | Snd = [R|Snds], merge(SndL, SndR, Snds).
merge(SndL, [R|SndR], Snd) :- true | Snd = [R|Snds], merge(SndL, SndR, Snds).
% outconv is used to prepare the output stream for outstream/1.
outconv([X|Xs1], Os0, N) :- true |
% Os0 = [write(X), nl|Os1],
Os0 = Os1,
N1 := N+1,
outconv(Xs1, Os1, N1).
outconv([], Os0, N) :- true |
Os0 = [write(N), write(' solutions'), nl].
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% puzzles...
initial(Slist,Plist) :- true |
squares(Slist),
piece_list(Plist).
% 6 solutions...
check_piece([o(X,Y,Z)|Rest], Status) :- X > 3 | Status = bad.
check_piece([o(X,Y,Z)|Rest], Status) :- Y > 0 | Status = bad.
check_piece([o(X,Y,Z)|Rest], Status) :- Z > 4 | Status = bad.
check_piece([o(X,Y,Z)|Rest], Status) :- X<4, Y<1, Z<5 |
check_piece(Rest, Status).
check_piece([], Status) :- true | Status = good.
piece_list(List) :- true | % shape # orientation
List = [orient( 1,[a,b,c,d,e,f]), % 4x2x1 (1)x(6)
orient( 4,[g,h,i])]. % 3x1x1 (4)x(3)
squares(List) :- true |
List =
[o(0,0,0),o(1,0,0),o(2,0,0),o(3,0,0),
o(0,0,1),o(1,0,1),o(2,0,1),o(3,0,1),
o(0,0,2),o(1,0,2),o(2,0,2),o(3,0,2),
o(0,0,3),o(1,0,3),o(2,0,3),o(3,0,3),
o(0,0,4),o(1,0,4),o(2,0,4),o(3,0,4)].
/*
% 2005 solutions...
check_piece([o(X,Y,Z)|Rest], Status) :- X<6, Y<6, Z<6 |
check_piece(Rest, Status).
check_piece([], Status) :- true | Status = good.
check_piece([o(X,Y,Z)|Rest], Status) :- X > 5 | Status = bad.
check_piece([o(X,Y,Z)|Rest], Status) :- Y > 5 | Status = bad.
check_piece([o(X,Y,Z)|Rest], Status) :- Z > 5 | Status = bad.
piece_list(List) :- true | % shape # orientation
List = [orient(13,[a,b,c,d,e,f]), % 4x2x1 (13)x(6)
orient( 3,[g,h,i]), % 3x1x1 (3)x(3)
orient( 1,[j,k,l]), % 2x2x1 (1)x(3)
orient( 1,[m])]. % 2x2x2 (1)x(1)
squares(List) :- true |
List =
[o(0,0,0),o(1,0,0),o(2,0,0),o(3,0,0),o(4,0,0),
o(0,1,0),o(1,1,0),o(2,1,0),o(3,1,0),o(4,1,0),
o(0,2,0),o(1,2,0),o(2,2,0),o(3,2,0),o(4,2,0),
o(0,3,0),o(1,3,0),o(2,3,0),o(3,3,0),o(4,3,0),
o(0,4,0),o(1,4,0),o(2,4,0),o(3,4,0),o(4,4,0),
o(0,0,1),o(1,0,1),o(2,0,1),o(3,0,1),o(4,0,1),
o(0,1,1),o(1,1,1),o(2,1,1),o(3,1,1),o(4,1,1),
o(0,2,1),o(1,2,1),o(2,2,1),o(3,2,1),o(4,2,1),
o(0,3,1),o(1,3,1),o(2,3,1),o(3,3,1),o(4,3,1),
o(0,4,1),o(1,4,1),o(2,4,1),o(3,4,1),o(4,4,1),
o(0,0,2),o(1,0,2),o(2,0,2),o(3,0,2),o(4,0,2),
o(0,1,2),o(1,1,2),o(2,1,2),o(3,1,2),o(4,1,2),
o(0,2,2),o(1,2,2),o(2,2,2),o(3,2,2),o(4,2,2),
o(0,3,2),o(1,3,2),o(2,3,2),o(3,3,2),o(4,3,2),
o(0,4,2),o(1,4,2),o(2,4,2),o(3,4,2),o(4,4,2),
o(0,0,3),o(1,0,3),o(2,0,3),o(3,0,3),o(4,0,3),
o(0,1,3),o(1,1,3),o(2,1,3),o(3,1,3),o(4,1,3),
o(0,2,3),o(1,2,3),o(2,2,3),o(3,2,3),o(4,2,3),
o(0,3,3),o(1,3,3),o(2,3,3),o(3,3,3),o(4,3,3),
o(0,4,3),o(1,4,3),o(2,4,3),o(3,4,3),o(4,4,3),
o(0,0,4),o(1,0,4),o(2,0,4),o(3,0,4),o(4,0,4),
o(0,1,4),o(1,1,4),o(2,1,4),o(3,1,4),o(4,1,4),
o(0,2,4),o(1,2,4),o(2,2,4),o(3,2,4),o(4,2,4),
o(0,3,4),o(1,3,4),o(2,3,4),o(3,3,4),o(4,3,4),
o(0,4,4),o(1,4,4),o(2,4,4),o(3,4,4),o(4,4,4)].
*/
------------------------------
End of PROLOG Digest
********************
∂09-Dec-87 1102 @Score.Stanford.EDU:CORNELIUS@SUMEX-AIM.Stanford.EDU You are invited - Computer Forum Poster Session
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Dec 87 11:02:02 PST
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 9 Dec 87 10:53:08-PST
Date: Wed, 9 Dec 87 10:57:20 PST
From: Craig Cornelius <Cornelius@SUMEX-AIM.Stanford.EDU>
Subject: You are invited - Computer Forum Poster Session
To: students@score.Stanford.EDU, csl-students@sierra.Stanford.EDU
cc: faculty@score.Stanford.EDU, forum@score.Stanford.EDU
Message-ID: <12357150918.16.CORNELIUS@SUMEX-AIM.Stanford.EDU>
This is a reminder about your chance to participate in the 20th Annual
Meeting of the Stanford Computer Forum, which will be held February 9
- 11, 1988 at Stanford. The program includes a student poster and
demonstration session for 2-1/2 hours on Wednesday afternoon, Feb. 10.
On behalf of the Forum Committee, I invite all PhD, MSCS, and MSAI
students to present their research at this session.
The poster session is an exciting opportunity for you to share your
research, learn about other work in our projects, and present your
ideas to an interested audience. There are also facilities for a few
demonstrations at the poster session, too.
The format is informal: Posters are displayed around a large room (in
CERAS Hall). At any given time, about 1/2 of the posters are
accompanied by a presenter, who answers questions and explains the
research to any and all who stop by.
You should work out the topic and format of your poster in
consultation with your research director. The material should be
aimed at an intelligent audience that is generally knowledgable about
computers, but not necessarily acquainted with the particular problem
and project you are presenting.
As "czar" of this activity, I need to know the following from
participants: (a) your name, (b) your topic, (c) your advisor,
definitely by mid-January. I'd also appreciate hearing from those who
expressed an interest earlier in the quarter.
The room size for this poster session is limited, and it is necessary
to reserve space by January 15 if you intend to participate. If you'd
like to present a demonstration using your computer equipment, please
let me know VERY SOON, since setting up demos will require special
arrangements.
Of course, please feel free to contact me with questions and
suggestions. I have several excellent posters prepared by KSL
students that you may examine for ideas on presentation.
Craig Cornelius
"Poster Czar" and Research Associate
Knowledge Systems Laboratory
725-3860
-------
∂09-Dec-87 1404 BERGMAN@Score.Stanford.EDU Winter quarter RAships
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Dec 87 14:04:35 PST
Date: Wed 9 Dec 87 13:57:55-PST
From: Sharon Bergman <BERGMAN@Score.Stanford.EDU>
Subject: Winter quarter RAships
To: faculty@Score.Stanford.EDU
Message-ID: <12357183792.33.BERGMAN@Score.Stanford.EDU>
If there are any changes in support for your research assistants for
Winter quarter, please let me know soon so that I can process the
paperwork. I need to be informed about any research assistants whose
appointments should be terminated as of Dec. 31 and any new RA appointments
beginning Winter quarter. If you want to change the source of support
on any of your students, let me know this also. For any new appointments,
please give me the name, source of support, percentage of time, and length
of appointment. Thanks.
-Sharon Bergman
-------
con-Dec-87 0839 RICHARDSON@Score.Stanford.EDU Faculty Lunch
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 10 Dec 87 08:39:24 PST
Date: Thu 10 Dec 87 08:32:24-PST
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: Faculty Lunch
To: faculty@Score.Stanford.EDU
Message-ID: <12357386677.10.RICHARDSON@Score.Stanford.EDU>
The next CSD faculty lunch will be on January 5, 1988. See you next year!
-------
∂10-Dec-87 0923 emma@russell.stanford.edu CSLI Calendar, December 10, 3:10
Received: from RUSSELL.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 10 Dec 87 09:23:24 PST
Received: from localhost by russell.stanford.edu (3.2/4.7); Thu, 10 Dec 87 08:48:49 PST
Date: Thu, 10 Dec 87 08:48:28 PST
From: emma@russell.stanford.edu
Subject: CSLI Calendar, December 10, 3:10
------- Blind-Carbon-Copy
To: friends
Subject: CSLI Calendar, December 10, 3:10
Date: Thu, 10 Dec 87 08:48:28 PST
From: emma
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
10 December 1987 Stanford Vol. 3, No. 10
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 10 December 1987
2:15 p.m. CSLI Seminar
Room G-19 Representation Strategies in LILOG
Redwood Hall Hans Uszkoreit
IBM Germany and University of Stuttgart
Abstract below
3:30 p.m. Tea
Ventura Hall
--------------
CSLI ACTIVITIES FOR THURSDAY, 17 December 1987
12 noon TINLunch
Ventura Hall To be announced
Conference Room
2:15 p.m. CSLI Seminar
Room G-19 The Integration of Syntax and Pragmatics
Redwood Hall through Abductive Inference
Jerry R. Hobbs
(Hobbs@Warbucks.ai.sri.com)
Abstract below
3:30 p.m. Tea
Ventura Hall
--------------
THIS WEEK'S SEMINAR
Representation Strategies in LILOG
Hans Uszkoreit
IBM Germany and University of Stuttgart
LILOG (Linguistic and Logic Methods for Knowledge-based Natural-Language
Understanding) is a basic research project funded by IBM Germany. It is
jointly conducted by the science and technology division of IBM Germany and
partner projects at five German universities. The long-term goal of the
project is to develop a knowledge-based text-understanding system for
German. The methods that are used in the design of the linguistic
components of LILOG share relevant features with ongoing work in the FOG
project at CSLI.
The talk will start with an overview of the objectives, organization, and
status of the project.
The underlying language for the representation of linguistic and extra-
linguistic knowledge is STUF (Stuttgart Type Unification Formalism). The
formalism has been implemented as a data type whose operations can be
utilized by all modules of the system. In addition to standard operations
such as unification, generalization, and subsumption, it provides for a
generalized version of functional application.
Newer developments of the STUF formalism include the integration of free-
arity and fixed-arity types and the introduction of knowledge domains.
Examples will be presented that demonstrate how the uniform formalism is
employed to account for the interaction of syntax and semantics.
--------------
NEXT WEEK'S SEMINAR
The Integration of Syntax and Pragmatics
through Abductive Inference
Jerry R. Hobbs
I will present the new method of abductive inference developed for SRI's
TACITUS project. This has resulted in a dramatic simplification in how
the problem of interpreting texts is conceptualized. It also suggests
an elegant and thorough means of integrating syntactic and pragmatic
processing, some details of which I will discuss.
------- End of Blind-Carbon-Copy
∂10-Dec-87 1541 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com Next MONDAY's Planlunch -- Vineet Singh
Received: from WARBUCKS.AI.SRI.COM by SAIL.STANFORD.EDU with TCP; 10 Dec 87 15:41:45 PST
Received: from venice by WARBUCKS.AI.SRI.COM via SMTP with TCP; Thu,
10 Dec 87 15:32:40-PST
Received: by venice (3.2/4.16) id AA04121 for
planlunch@warbucks.ai.sri.com; Thu, 10 Dec 87 15:38:13 PST
Date: Thu, 10 Dec 87 15:38:13 PST
From: Amy Lansky <lansky@venice.ai.sri.com>
Message-Id: <8712102338.AA04121@venice>
To: planlunch@warbucks.ai.sri.com
Subject: Next MONDAY's Planlunch -- Vineet Singh
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
DISTRIBUTING BACKWARD-CHAINING DEDUCTIONS TO MULTIPLE PROCESSORS
Vineet Singh (VSINGH@SPAR-20.ARPA)
Schlumberger Palo Alto Research
11:00 AM, MONDAY, December 14
SRI International, Building E, Room EJ228
This talk presents a parallel execution model called PM for
backward-chaining deduction with horn clauses. The target class of
multiprocessors for this work has the following properties: (1) there
are a finite number of MIMD processors; (2) each processor has a
finite amount of local memory; (3) there is no global memory; (4)
processors can communicate only by sending messages to each other; (5)
message delay is a function of the amount of data in the message and
the distance between source and destination; (6) each processor can
perform backward-chaining deductions based on the subset of the
program that it contains. For this multiprocessor class, PM can
exploit the most parallelism among existing execution models that use
data-driven control. In particular, PM can exploit or-parallelism,
and-parallelism, and pipelining.
One problem area that PM addresses is the design of a resource
allocator to map the parallel processes to hardware resources for
processing, storage, and communication. The allocation strategy
proposed is for use at compile-time (as opposed to run-time) and is
application-independent and multiprocessor-independent. This strategy
works subject to two restrictions. First, the type of
backward-chaining deduction is restricted. In particular, no
recursive clauses are allowed, unit clauses must be ground, and
certain probabilistic uniformity and independence assumptions must
apply. Second, a partitioning of the database is assumed to be given.
The allocator consists of an initial allocation phase followed by a
local minimization phase. In the initial allocation phase, database
partitions are allocated to processors one at a time using a greedy
algorithm. The local minimization phase consists of a sequence of
cost-reducing reallocations of partitions to neighboring processors.
Considerable speedups are obtained by using this allocation strategy.
These speedups compare favorably with an unreachable upper bound and
speedups obtained using random allocations.
∂10-Dec-87 1603 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Searches
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 10 Dec 87 16:03:42 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 10 Dec 87 15:56:05-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA04764; Thu, 10 Dec 87 14:23:45 PST
Date: Thu, 10 Dec 87 14:23:45 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8712102223.AA04764@Tenaya.stanford.edu>
To: faculty@score
Subject: Searches
We now have three searches for new faculty members going on:
These are for people in the areas of:
1) Programming Languages (non-conventional languages; billet 6.1).
Search Committee: Vaughan Pratt (chair), David Ungar, students
2) Computer Architecture (Katevenis replacement)
Search Committee: Anoop Gupta (chair), John Hennessy, students
3) General (Lantz Replacement) Can be in computer communications,
knowledge bases and databases ("area x"), interfaces, or software systems
depending on the excellence of the applicants.
Search Committee: David Cheriton (chair), Daniel Weise, students
In all three cases, the search committees will advertise, screen
candidates and then make recommendations of a short list to CSL
(acting as a committee of the whole). CSL will then make a
recommendation to CSD. We want to look particularly hard for women
and/or targeted minorities. The student bureaucrats should arrange to
have student representation on the committees.
Please forward suggestions about possible candidates to the appropriate
chairs. Thanks,
-Nils
∂10-Dec-87 1629 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU re: Searches
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 10 Dec 87 16:29:18 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 10 Dec 87 16:22:39-PST
Date: 10 Dec 87 1626 PST
From: Robert W Floyd <RWF@SAIL.Stanford.EDU>
Subject: re: Searches
To: nilsson@TENAYA.STANFORD.EDU, faculty@SCORE.Stanford.EDU
[In reply to message from nilsson@Tenaya.stanford.edu sent Thu, 10 Dec 87 14:23:45 PST.]
Do we really want to "look particularly hard for women and/or targeted minorities"?
Only if there is some evidence that such people, when qualified for posts like
ours, encounter discrimination at Stanford. If such people are scarce, it is
either the result of their preferences, etc., or the result of discrimination
along the way to the PhD; in either event, our giving a job to one of the survivors
does nothing to solve the problem that causes the scarcity. If they encounter
discrimination in the job market, there is no reason for Stanford to veer from
the line of selecting the best candidate because somebody else is prejudiced.
Our obligation is to advance the interests of our institution.
I assume that women, blacks, etc. qualified to profess here know how to find us.
If we hire someone who belongs to these groups, let it be without a hint that
we are doing her a special favor.
∂10-Dec-87 1920 @Score.Stanford.EDU:coraki!pratt@Sun.COM Searches
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 10 Dec 87 19:20:28 PST
Received: from Sun.COM by SCORE.STANFORD.EDU with TCP; Thu 10 Dec 87 19:12:00-PST
Received: from sun.Sun.COM by Sun.COM (4.0/SMI-3.2)
id AA06819; Thu, 10 Dec 87 19:13:32 PST
Received: from coraki.UUCP by sun.Sun.COM (4.0/SMI-4.0)
id AA05135; Thu, 10 Dec 87 19:14:16 PST
Received: by coraki.uucp (3.2/SMI-1.2)
id AA22511; Thu, 10 Dec 87 19:09:04 PST
Date: Thu, 10 Dec 87 19:09:04 PST
From: coraki!pratt@Sun.COM (Vaughan Pratt)
Message-Id: <8712110309.AA22511@coraki.uucp>
To: faculty@score.stanford.edu
Subject: Searches
Cc: coraki!pratt@Sun.COM
To reassure Bob in his concern about the conduct of the searches, as
the chair of one of the searches I would be disappointed if we did any
candidate a "special favor." We are interested only in those
candidates that are unambiguously of Stanford quality, and preferably
at the upper end of that range.
Having said that, I would add that I personally am concerned at the
current situation faced by women students in this department. While
female role models for men and male role models for women entail no
inconsistency, I have over the past fifteen years of my teaching career
heard quite a few students, both at MIT and Stanford, express a wish
for role models of their own sex. In this respect Stanford CSD, and
CSL for that matter now that Sue Owicki has left, is woefully behind
MIT in quantity and quality of female faculty who can inspire our
(many) female students. Are our female students to infer that women
are simply not as good as men in this field? If so then this must be
tremendously discouraging to them.
Furthermore I see little effort being put into correcting this, with
the result that at least one extremely talented female computer
scientist living in the area has recently gone elsewhere. I would hope
that my committee would be more activist about preventing such losses,
to the extent that this is possible without lowering our standards.
-v
∂11-Dec-87 0055 @Score.Stanford.EDU:coraki!pratt@Sun.COM Searches
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Dec 87 00:55:35 PST
Received: from Sun.COM by SCORE.STANFORD.EDU with TCP; Fri 11 Dec 87 00:49:26-PST
Received: from sun.Sun.COM by Sun.COM (4.0/SMI-3.2)
id AA06819; Thu, 10 Dec 87 19:13:32 PST
Received: from coraki.UUCP by sun.Sun.COM (4.0/SMI-4.0)
id AA05135; Thu, 10 Dec 87 19:14:16 PST
Received: by coraki.uucp (3.2/SMI-1.2)
id AA22511; Thu, 10 Dec 87 19:09:04 PST
Date: Thu, 10 Dec 87 19:09:04 PST
From: coraki!pratt@Sun.COM (Vaughan Pratt)
Message-Id: <8712110309.AA22511@coraki.uucp>
To: faculty@score.stanford.edu
Subject: Searches
Cc: coraki!pratt@Sun.COM
To reassure Bob in his concern about the conduct of the searches, as
the chair of one of the searches I would be disappointed if we did any
candidate a "special favor." We are interested only in those
candidates that are unambiguously of Stanford quality, and preferably
at the upper end of that range.
Having said that, I would add that I personally am concerned at the
current situation faced by women students in this department. While
female role models for men and male role models for women entail no
inconsistency, I have over the past fifteen years of my teaching career
heard quite a few students, both at MIT and Stanford, express a wish
for role models of their own sex. In this respect Stanford CSD, and
CSL for that matter now that Sue Owicki has left, is woefully behind
MIT in quantity and quality of female faculty who can inspire our
(many) female students. Are our female students to infer that women
are simply not as good as men in this field? If so then this must be
tremendously discouraging to them.
Furthermore I see little effort being put into correcting this, with
the result that at least one extremely talented female computer
scientist living in the area has recently gone elsewhere. I would hope
that my committee would be more activist about preventing such losses,
to the extent that this is possible without lowering our standards.
-v
∂11-Dec-87 0140 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #96
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Dec 87 01:40:03 PST
Date: Thu 10 Dec 1987 09:20-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #96
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Friday, 11 Dec 1987 Volume 5 : Issue 96
Today's Topics:
Query - Interfaces,
Theory - Impediments
----------------------------------------------------------------------
Date: 30 Nov 87 21:54:49 GMT
From: nosc!humu!uhmanoa!uhccux!todd@sdcsvax.ucsd.edu
Subject: Arity/Prolog and Microsoft C 5.0?
Has anyone successfully linked a Microsoft C (version 5.0) function
to Arity/Prolog 4.0? It seems like a lot has changed since Arity
wrote the "Building Arity/Prolog Applications" handbook. For example,
the handbook talks about an Arity supplied file called "arityc.h".
However, all I can find is "apctype.h" on my disks. It also seems that
some of the MSC compile options Arity says I must use to compile the C
code no longer exists in MSC version 5.0. Also, the Arity handbook
shows a C function called 'getint_c' being used to translate (I guess?)
parameters passed from Prolog to the C function. However, I can't
figure out where this function is supposed to come from.
-----------------------
Date: Tue 8 Dec 87 20:19:31-EST
From: Paul G. Weiss <PGW@XX.LCS.MIT.EDU>
Subject: Arity/Prolog and Msft C5.0
C5.0 works fine with A/P V4.0. The file apctype.h is the correct file,
arityc.h is a manual bug. Feel free to use /AL to compile (this also
works for C4.0). A/P V5.0 will support all the C models.
As for getint_c, it is provided in the ARITY.LIB. You are right in
that it is needed to translate parameters from Prolog to C. A/P V5
will do away with the need for this as it will allow you to declare
your C function and the types of its arguments from within your Prolog
source file.
------------------------------
Date: 8 Dec 87 20:19:13 GMT
From: iscuva!randyg@uunet.uu.net (Randy Gordon)
Subject: Re: Arity/Prolog and Microsoft C 5.0?
I just put up an example of linking arity prolog and C (version 4)
with the plink linker on the Arity Bulletin Board. Plink allows you
both multiple overlays and multiple overlay areas. With version 4
Arity, you have to add a few "class" statements to your plink command
file. (Not necessary using the microsoft linker).
In a couple of weeks version 5 of Arity Prolog will be out and the C
interface will be much cleaner(getint, etc dissapears... and you can
call prolog from C!)
------------------------------
Date: Wed, 9 Dec 87 17:45:36 PST
From: quintus!ok@Sun.COM (Richard A. O'Keefe)
Subject: A Theoretical Question
I'll start by briefly ignoring Sanjai Narain's question: the
super-exponentiality of Presburger Arithmetic has no more (and no less)
relevance to Prolog than to Lisp or ADA. We have known that resolution
is super-exponential since the mid-seventies. (I first saw this in one
of the Proc.Conf. Automata & Switching Theory volumes; sorry, don't
recall which.) A Prolog program to solve PA problems will be affected
by the result, as will a Prolog program to handle general resolution.
But so will a Lisp or ADA program for the same tasks.
Now for my theoretical question.
There is a significant difference between languages like ML and
Prolog and pure Lisp on one hand and languages like C and ADA and
the other FORTRAN look-alikes on the other hand. Assignment to
scalar variables is of no importance; what matters is that the
FORTRAN family has assignment to array elements, and the (pure) Lisp
family hasn't. (Yes, I *know* there are versions of Prolog which
have some sort of array facility. I am NOT asking about that.)
Basically, in order to maintain an array of N elements, a pure
language with bounded tuples of width T (pure Lisp: T=2, ALS Prolog:
T=14, some versions of C Prolog: T=100, others: T=200, Quintus Prolog:
T=255, DEC-10 Prolog: T>2000, ...) has to maintain a tree of
ceil(log(T,N))
levels. If you are accessing the elements of such a collection in
order, it takes unit time per element, and the same if you are building
a new collection in sequence. If you are accessing or constructing
a collection in other orders, it will usually cost a factor of
ceil(log(T,N)) per element. (Prolog can construct new collections
more cheaply than other declarative languages, thanks to the logical
variable. Turbo Prolog pays a high price here.)
For some applications, this doesn't matter. For example, the
Fast Fourier Transform on N numbers costs O(N.log(2,N)) time in a
member of the Fortran family. It turns out to be easy to write it
to take O(N.log(2,N)) time in a member of the (pure) Lisp family too.
Similarly, queue operations can be done in O(1) time both families.
But what about generating random permutations? Suppose we are
given a "sufficiently long" list of "pseudo-random" numbers, and a
data structure representing a collection, and want a new data
structure representing a permutation of the input.
QUESTION: Is there a data structure and algorithm such that
a permutation of N elements can be constructed in
O(N) time in a member of the (pure) Lisp family;
specifically in Prolog?
If N is bounded above by T, it is trivially easy.
A T-way divide-and-conquer yields an O(N.log(T,N)) algorithm,
for which "sufficiently long" means O(N.log(T,N)) random numbers.
The obvious attach-N-random-numbers-and-do-a-keysort is O(N.log(2,N)).
Can it be done in time O(N) for N >> T?
There is a sharper form of the question. Suppose we are given a
list whose elements form a permutation of {1...N}. That is, instead
of a "sufficiently long" list of random numbers, we have exactly N
integers.
QUESTION: Is there a data structure and algorithm such that
a permutation given as a list of N elements can be
applied in O(N) time, in ... Prolog?
This can certainly be done in O(N.log(T,N)) time by a T-way
divide-and-conquer.
QUESTION: If these things can't be done in linear time,
what bound can be proven?
I assume that tuples of size 0<=k<=T can be constructed in time O(k),
that the 1<=j<=k element of a tuple can be read in O(1) time, and
that an element which has not previously been set can be set in O(1)
time. I further assume that arithmetic operations cost O(1) time.
Now, for most practical purposes, O(N.log(200,N)) is nearly as
good as O(N): for any problem small enough to fit in a modern
computer, log(200,N) < 4. But coding a 200-way divide-and-conquer
is rather unpleasant. The Quintus routine random_permutation/2
actually takes O(N.log(2,N)) time because it was *so* much easier
to write. Perhaps someone can discover an O(N) method which is
simple as well as efficient?
------------------------------
End of PROLOG Digest
********************
∂11-Dec-87 0911 @Score.Stanford.EDU:dill@amadeus.stanford.edu faculty recruiting
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Dec 87 09:10:50 PST
Received: from amadeus.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 11 Dec 87 09:04:04-PST
Received: by amadeus.stanford.edu; Fri, 11 Dec 87 09:04:20 PST
Date: Fri, 11 Dec 87 09:04:20 PST
From: David Dill <dill@amadeus.stanford.edu>
Subject: faculty recruiting
To: faculty@score.stanford.edu
One should distinguish between giving special consideration to minorities
and women in getting them to apply and giving special consideration
in hiring. I know of several people who perhaps could have gotten
positions at Stanford but didn't apply, either because they thought
(incorrectly, I would guess) that they didn't have a chance at getting
the job, or because of concerns about Stanford's (obsolete, I hope)
reputation with respect to tenure. These people could be reached
by aggressive recruiting, with positive effects on the quality of
Stanford's faculty.
David Dill
∂11-Dec-87 1157 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Searches
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Dec 87 11:56:53 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 11 Dec 87 10:41:47-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA00169; Fri, 11 Dec 87 10:34:52 PST
Date: Fri, 11 Dec 87 10:34:52 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8712111834.AA00169@Tenaya.stanford.edu>
To: RWF@SAIL.stanford.edu
Cc: faculty@SCORE.stanford.edu
In-Reply-To: Robert W Floyd's message of 10 Dec 87 1626 PST <8712110027.AA04909@Tenaya.stanford.edu>
Subject: Searches
Bob,
I find your message about hiring women and targeted minorities quite
troubling. I think the matter can be rather simply put: The fact that
we have none of these on our faculty now is anomolous in the extreme
and impacts negatively on our ability to attract talented
women/minority students. I am sure that there are Stanford-quality,
excellent people out there (we have graduated many of them ourselves!)
I'm worried that without special efforts they might not bother to
apply. Because getting some women/minorities on our faculty would
have such a high payoff for us, I think we ought to work hard to do
so. Such a stance is completely consistent with wanting to hire no
one but the very best! Let's by all means do that. I am merely
suggesting that we try to convince some of those very best to apply.
-Nils
∂11-Dec-87 1157 REGES@Score.Stanford.EDU graduate level symbolic systems?
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Dec 87 11:57:27 PST
Date: Fri 11 Dec 87 11:12:36-PST
From: Stuart Reges <REGES@Score.Stanford.EDU>
Subject: graduate level symbolic systems?
To: faculty@Score.Stanford.EDU
Office: CS-TAC 22, 723-9798
Message-ID: <12357677985.25.REGES@Score.Stanford.EDU>
The Symbolic Systems Program is an undergrad degree program combining CS,
psych, linguistics, and philosophy. They are considering extending into
graduate level education, particularly the PhD level. I am interested in any
opinions the faculty might have off the top of their heads that I might pass
on. I'm sure they wouldn't proceed with these plans without setting up a more
formal discussion with the department faculty. Right now I'm just trying to
collect "straw poll" data. For example, half of the undergrads in symbolic
systems are pursuing the AI track. Will a graduate level symbolic systems
program end up competing with and perhaps diluting our efforts to turn out PhD
students in AI?
-------
∂11-Dec-87 1400 ULLMAN@Score.Stanford.EDU symbolic systems considered harmful
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Dec 87 14:00:05 PST
Date: Fri 11 Dec 87 13:52:39-PST
From: Jeffrey D. Ullman <ULLMAN@Score.Stanford.EDU>
Subject: symbolic systems considered harmful
To: faculty@Score.Stanford.EDU
Message-ID: <12357707122.29.ULLMAN@Score.Stanford.EDU>
I think SS is a big mistake. It gives the illusion that you
can solve hard problems sans a grounding in mathematics and real
computation. If it were up to me, I'd pull out if the SS UG program
and have nothing to do with any grad. programs.
---jeff
-------
∂11-Dec-87 1531 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU re: Searches
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Dec 87 15:31:24 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 11 Dec 87 15:24:36-PST
Date: 11 Dec 87 1529 PST
From: Robert W Floyd <RWF@SAIL.Stanford.EDU>
Subject: re: Searches
To: nilsson@TENAYA.STANFORD.EDU, RWF@SAIL.Stanford.EDU
CC: faculty@SCORE.STANFORD.EDU
[In reply to message from nilsson@Tenaya.stanford.edu sent Fri, 11 Dec 87 10:34:52 PST.]
Hmm. I see your point, Nils. But I am far from convinced. Our applicant
pool is rich in women students, and the last I knew they were accepting
our offers of admission at the same rate as the men. Is this not the case?
If we are in fact losing too many of our choices of students, the argument
holds some water.
Again, last I knew, the applicant pool was very light on targeted minorities,
by which I assume are meant black, native American, Latino, and Pacific
islanders. Is there anyy reason to think our faculty mix bears on this?
My assumption is that most of these ethnic groups look to other professions,
such as law, for advancement. Our affiliated faculty include what I think
are three people who would qualify as targeted minorities; are they
saturated with advisees for whom they are role models? It seems to me
that anyone who meets our standards for graduate admission or a teaching
post is going to be quite middle-class culturally, whatever the color.
If I grant your argument, shouldn't we be applying it in a different
direction? Students of east Asian origin, whether born here or there,
seem numerous, motivated, and well prepared here. For some there must
be serious difficulties with an unfamiliar language and culture. We
no lomger have any faculty in this class; should that get a higher priority?
It is not clear to me that there is a rational basis for the proposed
choice of groups to be searched for.
Lest I be misunderstood, my own position is that we should be very
careful to advertise our positions very broadly. Our reputation as a
place where nobody gets tenure is troubling, but whatever we do about
it should benefit our recruitment across the board; I don't see what
we can do to refute an idea that has a significant element of truth in it.
I am not in fact suggesting that we prefer any ethnic group; my previous
paragraph is aimed at showing where one ends up if you follow a line of
argument to the end.
∂11-Dec-87 1555 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Searches
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Dec 87 15:55:23 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 11 Dec 87 15:48:30-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA00592; Fri, 11 Dec 87 15:42:21 PST
Date: Fri, 11 Dec 87 15:42:21 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8712112342.AA00592@Tenaya.stanford.edu>
To: RWF@SAIL.stanford.edu
Cc: RWF@SAIL.stanford.edu, faculty@SCORE.stanford.edu
In-Reply-To: Robert W Floyd's message of 11 Dec 87 1529 PST <8712112318.AA00542@Tenaya.stanford.edu>
Subject: Searches
This discussion could go on for a while, I'm sure. I simply want
some women on the faculty. -Nils
∂11-Dec-87 1610 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU re: Searches
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Dec 87 16:10:24 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 11 Dec 87 16:03:49-PST
Date: 11 Dec 87 1608 PST
From: Robert W Floyd <RWF@SAIL.Stanford.EDU>
Subject: re: Searches
To: nilsson@TENAYA.STANFORD.EDU, RWF@SAIL.Stanford.EDU
CC: RWF@SAIL.Stanford.EDU, faculty@SCORE.STANFORD.EDU
[In reply to message from nilsson@Tenaya.stanford.edu sent Fri, 11 Dec 87 15:42:21 PST.]
So do I. But then, I'm single.
Does that count as a minority?
∂11-Dec-87 1811 SHOHAM@Score.Stanford.EDU ssp
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Dec 87 18:10:54 PST
Date: Fri 11 Dec 87 18:04:01-PST
From: Yoav Shoham <SHOHAM@Score.Stanford.EDU>
Subject: ssp
To: ullman@Score.Stanford.EDU
cc: faculty@Score.Stanford.EDU
Message-ID: <12357752882.32.SHOHAM@Score.Stanford.EDU>
Jeff,
I'd like to understand the reason for your view on SSP. I must
confess that, as someone who's both on the SSP committee and
who's interested in the interaction between
CS and other disciplines, I've been fairly enthusiastic about SSP.
Am I being starry eyed?
I agree that among the various ingredients of SSP, CS has the highest
density of knowledge. I also agree that there are those who substitute
wishful thinking for detailed representations and algorithms. But
I'm not convinced that those two properties exhaust the properties
of SSP.
First, I don't know that SSP is weak on rigor. It's certainly has less
CS content, but so do physics, chemistry and biology. It does have a
fair amount of logic and with the new changes will have reasonable
math requirements.
Second, it's not clear that understanding compilers
or networks or logic programs is intrinsically inferior to understanding
speech-act theory or Kantian philosophy or some such topic.
The fact that SSP graduates will be unemployable or unacceptable to
grad schools is in itself irrelevant to CS. I'm not sure it's true, either.
I guess that from the CS dept there are two contradictory potential
problems. First, that SSP will steal good students (and funding) from
us. Second, that SSP will accept our rejects, who will nonetheless
take our classes and claim to be doing AI (and by association CS),
and thus tarnish our reputation. I'm not that concerned about the latter,
provided there is adequate quality control. Again, you seem to think there
isn't, and I'd like to hear why. I'm too new here to have a balanced
image. I am somewhat concerned with losing AI students. I fear that
we have relatively few creative, unorthodox AI students, and those
might be swept off their feet by SSP.
Comments?
Yoav
-------
∂12-Dec-87 0053 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Satisfiability Problems in Propositional Logic
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Dec 87 00:53:25 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Sat 12 Dec 87 00:46:49-PST
Received: by lindy.stanford.edu; Sat, 12 Dec 87 00:49:43 PST
Received: by Forsythe.Stanford.EDU; Sat, 12 Dec 87 00:51:20 PST
Received: by NDSUVM1 (Mailer X1.24) id 0865; Sat, 12 Dec 87 01:43:37 CST
Date: 11 Dec 1987 11:29:38-EST (Friday)
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Klaus Truemper <KLAUS%UTD.EDU@relay.cs.net>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Klaus Truemper <KLAUS%UTD.EDU@relay.cs.net>
Subject: Satisfiability Problems in Propositional Logic
To: Local Distribution <AFLB.TN@sushi.stanford.edu>
I am working on theorem proving in first order logic, and would
like to obtain a set of satisfiability problems of the following
type:
-propositional logic
-clauses in CNF arising from actual decision problems, for example,
from problems of automation, or VLSI design.
-Size: up to several hundred clauses and several hundred literals.
If you can supply one or more such problems, I will be very grateful
if you make them available to me.
Klaus Truemper
Address: TRUEMPER@UTD.EDU
∂12-Dec-87 0101 @Score.Stanford.EDU:coraki!pratt@Sun.COM ssp
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Dec 87 01:01:26 PST
Received: from Sun.COM by SCORE.STANFORD.EDU with TCP; Sat 12 Dec 87 00:55:14-PST
Received: from sun.Sun.COM by Sun.COM (4.0/SMI-3.2)
id AA08043; Fri, 11 Dec 87 23:36:52 PST
Received: from coraki.UUCP by sun.Sun.COM (4.0/SMI-4.0)
id AA18797; Fri, 11 Dec 87 23:37:39 PST
Received: by coraki.uucp (3.2/SMI-1.2)
id AA25298; Fri, 11 Dec 87 23:33:54 PST
Date: Fri, 11 Dec 87 23:33:54 PST
From: coraki!pratt@Sun.COM (Vaughan Pratt)
Message-Id: <8712120733.AA25298@coraki.uucp>
To: faculty@score.stanford.edu
Subject: ssp
Yoav is defending the subject while Jeff is criticizing the work.
That's no less consistent than defending the presidency while
criticizing the incumbent.
-v
∂12-Dec-87 1153 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU re: ssp
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Dec 87 11:53:27 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sat 12 Dec 87 11:15:03-PST
Date: 12 Dec 87 1120 PST
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: re: ssp
To: faculty@SCORE.Stanford.EDU
[In reply to message from SHOHAM@Score.Stanford.EDU sent Fri 11 Dec 87 18:04:01-PST.]
I also think the blast at SSP requires more justification.
While I'm at it, let me express doubt about affirmative action.
In the main it's just reshuffling the qualified and interested
women. However, the role model business worries me. In the
first place it's dubious psychology and sociology. In the second
place, I remember when a woman candidate was criticized on the
grounds that while she was ok scientifically, she wasn't suitable
as a role model for the female graduate students.
∂13-Dec-87 1059 @Score.Stanford.EDU:cheriton@pescadero.stanford.edu Re: graduate level symbolic systems?
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 Dec 87 10:59:41 PST
Received: from pescadero.stanford.edu by SCORE.STANFORD.EDU with TCP; Sun 13 Dec 87 10:51:52-PST
Received: by pescadero.stanford.edu; Sun, 13 Dec 87 10:56:35 PST
Date: Sun, 13 Dec 87 10:56:35 PST
From: David Cheriton <cheriton@pescadero.stanford.edu>
To: REGES@score.stanford.edu, faculty@score.stanford.edu
Subject: Re: graduate level symbolic systems?
I understand there is strong support at the SOE and Provost level to
computer science at Stanford in one department, and avoid having numerous
departments pretend to do computer science just because they monkey
with computers. I think this is a good objective.
I can imagine a need and benefit for a symbolic systems program in
philosophy, etc. graduate and undergraduate. I can appreciate the
students taking a few computing courses. And I have no objection to
this program as such. However, without evidence strongly to the contrary,
I would regard the students of this program no more as computer scientists
than the occasional GSB students that take my classes. I would similarly
object to any effort in this program to dilute the "one computer science dept."
objective.
Otherwise, I welcome their grad. program. Any students we lose to their
program are probably better off there for all concerned, although I dont
know what the employment prospects are for their grads.
David Cheriton
∂13-Dec-87 1121 @Score.Stanford.EDU:cheriton@pescadero.stanford.edu Faculty search heuristics
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 Dec 87 11:21:26 PST
Received: from pescadero.stanford.edu by SCORE.STANFORD.EDU with TCP; Sun 13 Dec 87 11:13:58-PST
Received: by pescadero.stanford.edu; Sun, 13 Dec 87 11:18:42 PST
Date: Sun, 13 Dec 87 11:18:42 PST
From: David Cheriton <cheriton@pescadero.stanford.edu>
To: faculty@score.stanford.edu
Subject: Faculty search heuristics
Whatever their sex and color, excellent candiates are in short support and high
demand. I understand that George Forsythe make extraordinary efforts to
get some of the pillars of the department to come here.
I am trying to very actively search out and interest the best candidates
in the OS, distributed systems and communications areas. I would appreciate
any suggestions on candidates, leads or heuristics - in case I have missed
or likely to miss something. Thanks.
David Cheriton
∂13-Dec-87 1605 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Jean Rogers
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 Dec 87 16:05:26 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Sun 13 Dec 87 15:58:27-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA01927; Sun, 13 Dec 87 16:03:48 PST
Date: Sun, 13 Dec 87 16:03:48 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8712140003.AA01927@Tenaya.stanford.edu>
To: ac@score
Subject: Jean Rogers
Jean Rogers, one of our lecturers, comes up for a re-hire
decision in Winter Quarter. It's important that we have the
very best lecturers we can find. I need a volunteer from the
faculty to look over various comments we have about Jean, perhaps
to attend one or two of her classes, talk to some of the students,
look at the TBPs, and make a recommendation to the faculty about
rehire. It would be best to have perhaps two people do this
as a team. Thanks, -Nils
∂13-Dec-87 1825 @Score.Stanford.EDU:FEIGENBAUM@SUMEX-AIM.Stanford.EDU Re: symbolic systems considered harmful
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 Dec 87 18:25:45 PST
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 13 Dec 87 18:18:15-PST
Date: Sun, 13 Dec 87 18:23:43 PST
From: Edward Feigenbaum <FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
Subject: Re: symbolic systems considered harmful
To: ULLMAN@score.Stanford.EDU, faculty@score.Stanford.EDU
In-Reply-To: <12357707122.29.ULLMAN@Score.Stanford.EDU>
Message-ID: <12358280756.17.FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
I am neither specifically a supporter nor a detractor of Symbolic Systems UG.
I too am puzzled by Jeff's "flame". I've searched my e-mail to find
something to which he was responding, to try to put all of this in context
of something. I couldn't find anything. Can someone illuminate this?
The point of an undergrad degree is, to a large extent, intellectual
stimulation and nurturing, not "preparation for jobs". Students can
prepare for jobs by going to grad school for MS or MBA or Law, etc.
It seems to me that interdisciplinary philosophy/linguistics/psychology/AI
is excellent intellectual stimulation. It isn't CS, but why should we care?
Re mathematics...that seems to be a red herring. There's a lot in a
university catalog that isn't mathematical, even in the sciences, even
in the truly superb sciences (e.g. molecular biology).
As you can see, I'm trying to understand the real issue. Is it that we
are embarrassed to be part of SS/UG because it is poorly taught and
administered?
Ed
-------
∂13-Dec-87 2012 @Score.Stanford.EDU:FEIGENBAUM@SUMEX-AIM.Stanford.EDU Re: graduate level symbolic systems?
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 Dec 87 20:12:37 PST
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 13 Dec 87 20:05:07-PST
Date: Sun, 13 Dec 87 20:10:33 PST
From: Edward Feigenbaum <FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
Subject: Re: graduate level symbolic systems?
To: REGES@score.Stanford.EDU, faculty@score.Stanford.EDU
In-Reply-To: <12357677985.25.REGES@Score.Stanford.EDU>
Message-ID: <12358300203.17.FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
OK, I found it...sorry. It was a message from Stuart. So the real issue
seems to be the proposed extension to the Ph.D. level, not the UG program
or its quality.....Ed
-------
∂13-Dec-87 2259 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com REMINDER -- Monday Planlunch -- Vineet Singh
Received: from WARBUCKS.AI.SRI.COM by SAIL.STANFORD.EDU with TCP; 13 Dec 87 22:58:54 PST
Received: from venice by WARBUCKS.AI.SRI.COM via SMTP with TCP; Sun,
13 Dec 87 22:45:22-PST
Received: by venice (3.2/4.16) id AA06094 for
planlunch_reminder@WARBUCKS.ai.sri.com; Sun, 13 Dec 87 22:51:49 PST
Date: Sun 13 Dec 87 22:51:47-PST
From: Amy Lansky <LANSKY@venice.ai.sri.com>
Subject: REMINDER -- Monday Planlunch -- Vineet Singh
To: planlunch_reminder@WARBUCKS.ai.sri.com
Message-Id: <566463107.0.LANSKY@VENICE.ARPA>
Mail-System-Version: <SUN-MM(213)+TOPSLIB(128)@VENICE.ARPA>
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
DISTRIBUTING BACKWARD-CHAINING DEDUCTIONS TO MULTIPLE PROCESSORS
Vineet Singh (VSINGH@SPAR-20.ARPA)
Schlumberger Palo Alto Research
11:00 AM, MONDAY, December 14
SRI International, Building E, Room EJ228
-------
∂14-Dec-87 0144 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #97
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 14 Dec 87 01:43:59 PST
Date: Sun 13 Dec 1987 10:30-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #97
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Monday, 14 Dec 1987 Volume 5 : Issue 97
Today's Topics:
Announcement - Call for Kitchen Sink & Fellowship Available,
Theory - Impediments
----------------------------------------------------------------------
Date: 10 Dec 87 23:28:09 GMT
From: munnari!mulga!isaac@uunet.uu.net (Isaac Balbin)
Subject: Call For Papers
Call for Papers
International Computer Science Conference '88
Artificial Intelligence: Theory and Applications
International Computer Science Conference '88 is to be the first
international conference in Hong Kong devoted to computer science. The
purpose of the conference is to bring together people from academia
and industry of the East and of the West, who are interested in
problems related to computer science. The main focus of this
conference will be on the Theory and Applications of Artificial
Intelligence. Our expectation is that this conference will provide a
forum for the sharing of research advances and practical experiences
among those working in computer science.
Topics of interest include, but are not limited to:
AI Architectures Expert Systems Knowledge Engineering
Logic Programming Machine Learning Natural Languages
Neural Networks Pattern Recognition Robotics
CAD/CAM Chinese Computing Distributed Systems
Information Systems Office Automation Software Engineering
Paper Submissions
Submit four copies of the paper by June 15, 1988 to either of the Program
Co-Chairmen:
Dr. Jean-Louis Lassez Dr. Francis Y.L. Chin
Room H1-A12 Centre of Computer Studies and
IBM Thomas J. Watson Applications
Research Center University of Hong Kong
P.O. Box 218 Pokfulam Road
Yorktown Heights NY Hong Kong
10598 (For papers from Pan-Pacific region
U.S.A. only)
e-mail: JLL@ibm.com e-mail: hkucs!chin@uunet.uu.net
The first page of the paper should contain the author's name,
affiliation, address, electronic address if available, phone number,
100 word abstract, and key words or phrases. Papers should be no
longer than 5000 words (about 20 double-spaced pages). A submission
letter that contains a commitment to present the paper at the
conference if accepted should accompany the paper.
Tutorials
The day after the conference will be devoted to tutorials. Proposals
for tutorials on Artificial Intelligence topics, especially advanced
topics, are welcome. Send proposals by June 15, 1988 to the Program
Co-Chairmen.
Conference Timetable and Information
Papers due: June 15, 1988
Tutorial proposals due: June 15, 1988
Acceptance letters sent: September 1, 1988
Camera-ready copy due: October 1, 1988
In cooperation with;
Center for Computing Studies and Services, Hong Kong Baptist College
Centre of Computer Studies and Applications, University of Hong Kong
Department of Computer Science, The Chinese University of Hong Kong
Department of Computer Studies, City Polytechnic of Hong Kong
Department of Computing Studies, Hong Kong Polytechnic
------------------------------
Date: 8 Dec 87 02:07:57 GMT
From: munnari!mulga!rwt@uunet.uu.net (Rodney Topor)
Subject: Research Fellowship Available
Applications are invited for a Research Fellow (Grade 2) to work on
the Machine Intelligence Project in the Department of Computer Science
at the University of Melbourne.
This internationally recognized project is performing research into
knowledge-based systems, databases, logic programming, parallel compu-
ting, and programming environments. Project facilities include a
network of SUN workstations and access to other departmental computers
and networks. The project is supported by the ARGS and DITAC.
Applicants should have a PhD or equivalent qualifications and research
experience in appropriate areas. The appointee will be expected to
perform independent and joint research in any one or more of the
project research areas.
The period of appointment is from 1 January 1988 to 31 December 1988,
with an expectation of renewal in 1989, and possible subsequent
renewals.
Salary: A$28,380 to A$37,122 per annum depending on qualifications and
experience.
Mail enquiries to Dr K.R. Rao (rao@mulga.oz.au) or Dr R.W. Topor
(rwt@mulga.oz.au).
Applications quoting Position Number 622A845 and including full per-
sonal and academic details and the names and addresses of two referees
should be sent to Director, Personnel Services, University of Mel-
bourne, Parkville, Vic. 3052, Australia. Further information regarding
details of application procedure and conditions of appointment is
available from Mr Butters +61 3 344 7546.
Closing date: 18 December 1987.
------------------------------
Date: Fri, 11 Dec 87 12:21:34 PST
From: narain%pluto@rand-unix.ARPA
Subject: Reply to O'Keefe
Results about complexity of proof-procedures may not be relevant to
Prolog, but are certainly relevant to SLD-resolution which was born in the
world of theorem proving. If complexity results which apply to general
resolution also apply to it, what then is its importance? Kowalski
pointed out that its importance is its **procedural interpretation**.
Well, why doesn't general resolution have a procedural
interpretation?..... I believe it has to do with the fact that its
behavior is more difficult to visualize and predict than that of
SLD-resolution. Any proponents of programming in full-first order logic
care to comment?
For similar points, see also J.A. Robinson's introduction in the first
issue of the Journal of Logic Programming, and also Logic programming with
equatons, by M. van Emden and K. Yukawa, Tech report CS-86-05 University
of Waterloo.
-- Sanjai Narain
------------------------------
Date: Sun, 13 Dec 87 00:19:35 PST
From: quintus!ok@Sun.COM (Richard A. O'Keefe)
Subject: Theoretical question
I've had a little bit of mail in answer to this.
The method for generating a random permutation of a list is
very direct. Oddly enough, it looks like quick-sort, which
is a pretty appalling sorting algorithm, because it cannot
guarantee an even partition, but here we can.
random_permutation(A, B) :-
same_length(A, B, N),
random_permutation(N, A, B, []).
random_permutation(0, [], B, B).
random_permutation(1, [X], [X|B], B).
random_permutation(N, A, B0, B) :-
N >= 2,
P is N >> 1,
Q is N - P,
random_partition(P, N, A, X, Y),
random_permutation(P, X, B0, B1),
random_permutation(Q, Y, B1, B).
random_partition/5 makes a random partition of A into a subseqence X
having P elements and a complementary subsequence Y having Q = N-P
elements. That needs no explanation; you'll find the method in Knuth,
and in Bentley, and I sent a C version to comp.sources. I pass the
length N of the list A around for efficiency, recomputing it would
not change the O(N.lgN) bound.
If you have terms of unbounded length, it should be obvious that
you can APPLY a permutation of [1..N] in O(N) time:
apply_permutation(Permutation, A, B) :-
length(Permutation, N),
same_functor(A, B, f, N),
apply_permutation(Permutation, 0, A, B).
apply_permutation([], _, _, _).
apply_permutation([P|Ps], I, A, B) :-
J is I+1,
arg(I, A, X),
arg(P, B, X),
apply_permutation(Ps, J, A, B).
Note that it is not feasible to solve for the permutation: for
terms of length N there could be as many as N! permutations to
enumerate.
Even with terms of unbounded length, it is not clear whether a
random permutation of [1..N] can be constructed in O(N) time.
It is easy to do in a conventional language, but any one element
of the array may be changed several times.
An obvious technique is something like this:
make a term with k*N arguments, for some fixed k
make a pass over the input, trying to put each
item into a randomly chosen argument of the term.
If the argument has already been filled, divert
the item to an overflow list.
Read the permutation off the term, ignoring unset
arguments.
If the overflow list is empty, stop.
Otherwise, generate a random permutation of the overflow
list, and append it to the read-off list.
The most straightforward approach chips off ~0.63N elements in the
first pass, so
cost(N) = c.N + cost(0.27N)
cost(N) = (c/0.27)N is a solution of this equation, so this gives
us a linear-expected-time algorithm for generating random permutations
if you have terms of unbounded length available. The worst case
appears to be O(N**2) (it has quicksortitis) but it is very unlikely.
Obviously it is possible to attain a version with O(N.lgN) worst case
by monitoring the cost so far, and when the cost so far reaches
N.lgN random number generations, switch over to another method.
But is there a more direct modification with an O(N.lgN) worst case?
Note that this approach requires a hack:
we have to be able to tell whether a particular argument
of the working term has been filled in or not.
We can distinguish eight levels of power:
1a) PURE FUNCTIONAL LANGUAGES.
tuples are created with ground elements.
tuples are bounded by some constant T characteristic of
the given program.
1b) PURE FUNCTIONAL LANGUAGES + ARRAY-FORMING OPERATOR.
tuples are created with ground elements.
there is no prior bound on the size of a tuple.
Typically there are functions
mk-array f n : (int -> *) -> int -> * array
array-elt a n : (* array) -> int -> *
satisfying array-elt (mk-array f N) i = f i, for 1<=i<=N
2a) PURE HORN CLAUSE LANGUAGES.
tuples are created with arbitrary terms as elements.
there is an arg(N,T,A) operation, but no var/1 or !/0
tuples are bounded by some constant T characteristic of
the given program.
Note that a program in such a language has no way of
telling whether a particular element has been set or not.
2b) PURE HORN CLAUSE LANGUAGES + ARRAY-FORMING OPERATOR.
As 2a) + functor(T,F,N), where N has no prior bound.
3a) BOUNDED-TERM PROLOG.
as 2a) + var/1 or !/0.
Most Prologs are in this class.
What you get here are write-once arrays where you can tell
whether a particular element has been written yet or not.
3b) UNBOUNDED-TERM PROLOG.
as 2b) + var/1 or !/0.
I think DEC-10 Prolog was in this class (I never found a bound
other than memory size, which was NOT large, as Edinburgh never
had an extended-addressing machine), I think POPLOG is in this
class, and I have been told that VM/PROLOG is in this class.
You can emulate conventional arrays in this class; array access
and update have O(1) expected cost and O(N) worst case cost;
I haven't analysed the use of this method for permutations yet.
Also, the emulation doesn't make anything remotely resembling
logical sense.
4a) BOUNDED-ARRAY IMPERATIVE LANGUAGES.
Conventional arrays can be made. Elements can be accessed and
updated in O(1) average and worst case time, and any element
can be updated any number of times. However, the size of an
array is bounded.
Most programming languages are in this class. Or rather, their
implementations are. For example, on the B6700, the absolute
maximum size for an array was 2↑20 words. (An array could have
arrays as elements, so you could have data structures that were
larger, but it took more than one step to get to the leaves.)
I used to use a Fortran compiler where an array could not
contain more than 2↑16 16-bit words, even though the machine
was supposed to have an address space of 2↑28 16-bit words.
On a typical UNIX system, the size of local arrays in C or
PASCAL had better be limited!
If we're really honest about it, even implementations which impose
no prior restrictions on the size of arrays are not accurately
modelled by the RAM model for large data structures: the pointers
which make these things really trees are there, but they are in
the operating system's paging tables.
4b) UNBOUNDED-ARRAY IMPERATIVE LANGUAGES.
4a) + no prior bound on array size other than machine memory.
This is what most programmers think they've got.
Now, remember that we can solve the permutation problems with
T-bounded terms in O(N) space and O(N.log(T,N)) time in languages
of class 1a). It is straightforward to write the code for T=8.
For 2↑30 words (all you can fit in a 32-bit byte-addressed machine),
log(8,N) <= 10, so the difference between O(N.log(8,N)) and O(N) is
not all that great. For problems bigger than that, the pretence of
languages like Pascal to belong to class 4b) -- reading "machine
memory" as "store + disc space" -- is unpleasantly exposed.
One of the reasons for being interested in functional languages at
all is the hope that they might be useful for parallel systems.
The connection between forming permutations and data routing in
networks of processors is fairly clear, and connection networks
provide each processor with a fixed smallish number of neighbours.
O(1) access and update time across such a network is out.
There are a lot of problems where languages of class 1a) are no worse
than languages of class 4b): the Fast Fourier transform is one,
transposing a matrix is another. In these two cases, we are shuffling
data around, but we can analyse the shuffle in advance and route the
data so that each "Logical Inference" moves a bounded number of items
a bounded number of hops.
Where we are with respect to the permutation problems:
generating a random permutation (of any list) is
O(N.log(T,N))
in a language of class 1a) or better, or
O(N) average, O(NlgN) worst case
in a language of class 3b) or better, or
O(N) average and worst case
in a language of class 4b)
These are upper bounds. O(N) is a lower bound.
Can these bounds be tightened? Allan van Gelder showed me a
random permutation method once for class 3b), and I have a
nasty feeling it was O(N) worst case, but I can't find my copy.
It is trivially easy to show that if bound O(f(N)) is attainable
for some algorithm in a language of class 4b), a bound of
O(f(N).T.log(T,N)) is attainable in a language of class 1a).
Often O(f(N)) is attainable.
What I'm hoping is that someone will be able to think of some
general techniques, either proof methods for showing that certain
problems must suffer, or coding methods for showing that they
needn't.
It is worth noting that in parallelising conventional algorithms,
paying an O(lgN) time and space cost by allocating new data
instead of changing the old may permit a subsequent O(N) time
speedup, for a speedup of O(N/lgN) relative to the original
algorithm. I am not skilled in such matters, but I believe that
permutation generation may be such a case. (That is, with N
processors, it would take lg(N) parallel steps). Anyone know?
------------------------------
End of PROLOG Digest
********************
∂14-Dec-87 0858 RICHARDSON@Score.Stanford.EDU Faculty Meeting
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 14 Dec 87 08:57:59 PST
Date: Mon 14 Dec 87 08:49:04-PST
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: Faculty Meeting
To: faculty@Score.Stanford.EDU
Message-ID: <12358438286.13.RICHARDSON@Score.Stanford.EDU>
General Faculty Meeting
January 5, 1988
2:30 p.m.
MJH 146
Agenda
======
1. Approval of degree candidates, Sharon Hemenway
2. Staff Reports
3. Faculty Actions:
a. Courtesy Appointment for Prof. David Rumelhart, Psychology
-Nils Nilsson
b. Consulting Professorship for Keith Lantz
-John Hennessy
c. Consulting Professorship for Moshe Vardi
-Jeff Ullman
d. Visiting Professorship for Neil Jones (Winter Quarter)
-John McCarthy
e. Proposed policy regarding reversion of unrestricted funds and
equipment when faculty/staff leave Stanford
-Nils Nilsson
f. Proposed policy change regarding departmental share of assignment of
rights income (see Nilsson e-mail)
-Nils Nilsson
-------
∂14-Dec-87 0903 RICHARDSON@Score.Stanford.EDU Tenured Faculty Meeting
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 14 Dec 87 09:03:00 PST
Date: Mon 14 Dec 87 08:51:25-PST
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: Tenured Faculty Meeting
To: tenured@Score.Stanford.EDU
Message-ID: <12358438715.13.RICHARDSON@Score.Stanford.EDU>
Tenured Faculty Meeting
January 5, 1988
4:00 p.m.
MJH 146
Agenda
======
1. Consideration of promotion of Asst. Professor Ernst Mayr to Assoc.
Professor (with tenure)
-Bob Floyd
-------
∂14-Dec-87 1055 X3J13-mailer March meeting
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 14 Dec 87 10:55:42 PST
Received: by labrea.stanford.edu; Mon, 14 Dec 87 10:44:55 PST
Received: from sunvalleymall.lucid.com by edsel id AA06718g; Mon, 14 Dec 87 10:19:51 PST
Received: by sunvalleymall id AA10259g; Mon, 14 Dec 87 10:20:42 PST
Date: Mon, 14 Dec 87 10:20:42 PST
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8712141820.AA10259@sunvalleymall.lucid.com>
To: labrea!x3j13%sail.stanford.edu@labrea.stanford.edu
Subject: March meeting
X3J13
3/14/88 - 3/18/88
Palo Alto, CA
The next meeting of X3J13 will be held from 9:00am, Wednesday, March 16,
1988 until 5:00pm, Thursday, March 17, 1988, at the Hyatt Rickeys in Palo
Alto, CA. The meeting will be held in the Executive Conference Room.
Subcommittee meetings will be held Monday, March 14, Tuesday, March 15 and
Friday, March 18.
Please let me know if and when your subcommittee will be meeting in Palo
Alto in March. I need to reserve small rooms now if they're necessary. In
the interest of saving money, if you have a subcommittee member who is local
perhaps the meeting could be held at their company.
For example: the CLOS subcommittee will meet at Lucid
Monday, 3/14 and Tuesday 3/15 at 10:00. Friday's time is
yet to be determined.
A block of rooms is available at the Hyatt Rickeys. The rate will be $84 a
night (plus tax). A limited number of rooms are available for non-smokers.
Please call (800) 228-9000 or (415) 493-8000 before February 26 to receive
the discounted rate. Be sure to mention "X3J13 Standards Committee".
Thank you Dave Matthew for letting us use the HP discount!
Before I call and get special airline fares I'd like to know if anyone has
found this to be useful. If I get no replies I'll assume it's not necessary
to set up special fares.
Refreshments will be available during the morning (8:00am) and afternoon
sessions. Lunch will be available Wednesday, March 16 and Thursday, March
17. If you have dietary restrictions please complete the appropriate
section below.
The cost per person for food service and conference room rental is $55.00.
Please include a check for this amount, payable to Lucid, with the
registration form.
I will be happy to arrange a group dinner for Wednesday, March 16. Someone
has suggested we go to Watercourse Way in Palo Alto for sushi dinner and go
hot tubbing afterwards at (combined fee of around $25) If interested, please
note this in the appropriate space below.
N San Francisco Airport
W E |
S | | 101
------------------------------------------92
| |
| |
| |
| |
| | 101
Foothills | | San Francisco Bay
| |
| |
|X Hyatt Rickeys |
| |
|El Camino Real |
| |
Los Altos ----------------------------------------San Antonio Road
| |
| |
San Jose Airport
!
Directions from San Francisco airport to Hyatt Rickeys: Take 101 south to
San Antonio Road (about 25 minutes in non-rush hour traffic). Take San
Antonio Road exit marked Los Altos, heading toward the hills. Turn right
on El Camino Real. The hotel is on the right at 4219 El Camino Real, Palo
Alto, CA 94306 (415) 493-0800. Hertz, Avis and National car rentals are
within 1 block.
Directions from San Jose airport: Take 101 north to San Antonio Road (about
15 minutes in non-rushhour traffic). Take San Antonio Road exit marked Los
Altos, heading toward the hills. Turn right on El Camino Real. The hotel
is on the right at 4219 El Camino Real, Palo Alto, CA 94306 (415) 493-0800.
A shuttle service is available though Airport Connection for $12.00.
Pickup points are located directly outside each terminal baggage claim area
at the center traffic island. Shuttle will stop at each blue striped
pillar. The shuttle stops in Menlo Park, Standford and then Hyatt Rickeys.
The schedule from San Francisco Airport to Palo Alto follows:
* *
LV Menlo Stan- Palo Sunny- San ARR
SFO Park ford Alto vale Jose SJC
7:01A 7:20A 7:35A 7:40A 8:00A 8:25A 8:30A Daily
8:16A 8:40A 8:50A 8:55A 9:20A 9:40A 9:45A Ex. Sat
9:11A 9:35A 9:42A 9:46A 10:05A 10:30A 10:35A Daily
11:00A 11:25A 11:30A 11:35A 12:01P 12:25P 12:30P Ex. Sat
12:01P 12:25P 12:30P 12:35P 1:00P 1:25P 1:30P Daily
1:00P 1:25P 1:30P 1:35P 2:00P 2:25P 2:30P Ex. Sat
2:01P 2:30P 2:35P 2:40P 3:10P 3:40P 3:45P Daily
3:06P 3:35P 3:40P 3:45P 4:10P 4:40P 4:45P Ex. Sat
4:01P 4:30P 4:35P 4:40P 5:05P 5:35P 5:40P Daily
5:20P 5:50P 5:55P 6:00P 6:25P 6:50P 6:55P Ex. Sat
6:50P 7:20P 7:25P 7:30P 7:50P 8:15P 8:20P Daily
8:40P 9:05P 9:10P 9:15P 9:40P 10:00P 10:10P Ex. Sat
10:10P 10:40P 10:45P 10:50P 11:15P 11:35P 11:45P Daily
Shuttle service from Palo Alto to San Francisco Airport:
* *
LV SJC Sunny- Palo Stan- Menlo AR
San Jose vale Alto ford Park SFO
5:25A 5:30A 5:40A 6:08A 6:22A 6:27A 7:00A Daily
6:15A 6:20A 6:35A 7:08A 7:25A 7:30A 8:15A Ex. Sat
7:25A 7:30A 7:45A 8:13A 8:32A 8:37A 9:10A Daily
8:25A 8:30A 8:45A 9:13A 9:32A 9:37A 10:10A Ex. Sat
9:40A 9:45A 9:55A 10:23A 10:37A 10:42A 11:15A Daily
10:30A 10:35A 10:45A 11:08A 11:22A 11:27A 12:05P Ex. Sat
12:25P 12:30P 12:40P 1:08P 1:22P 1:27P 2:00P Daily
1:25P 1:30P 1:40P 2:08P 2:22P 2:27P 3:05P Ex. Sat
2:25P 2:30P 2:40P 3:08P 3:22P 3:27P 4:00P Daily
3:40P 3:45P 3:55P 4:25P 4:44P 4:49P 5:19P Ex. Sat
4:55P 5:00P 5:15P 5:45P 6:05P 6:10P 6:40P Daily
6:50P 6:55P 7:05P 7:30P 7:45P 7:50P 8:20P Ex. Sat
8:15P 8:20P 8:30P 8:55P 9:10P 9:15P 9:45P Daily
Feel free to contact me if you have any questions.
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
edsel!jlz@labrea.stanford.edu
(415) 329-8400
!
X3J13 March Meeting Registration Form
Please include check for $55.00 payable to Lucid mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
!
Name: _____________________________________________________________
Institution: ______________________________________________________
Street Address: ___________________________________________________
City: ________________ State: ___ Phone: ________________________
Net-Address: ______________________________________________________
Lunch 3/18: yes _______ no _______
Lunch 3/17: yes _______ no _______
Dietary Restrictions:_______________________________________________
Sushi Dinner 3/16: yes ______ something else ______
Hot tubbing 3/16: yes ______ something else ______
Set up special airline fares: yes _______ no _______
Subcommittee Name: _________________________________________________
Subcommittee Chair: ________________________________________________
____ We need a meeting room
____ We will be meeting at _________________________________________
∂14-Dec-87 1127 emma@russell.stanford.edu Revised title and abstract for CSLI Seminar
Received: from RUSSELL.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 14 Dec 87 11:27:15 PST
Received: from localhost by russell.stanford.edu (3.2/4.7); Mon, 14 Dec 87 10:34:07 PST
Date: Mon, 14 Dec 87 10:33:52 PST
From: emma@russell.stanford.edu
Subject: Revised title and abstract for CSLI Seminar
------- Blind-Carbon-Copy
To: friends
Subject: Revised title and abstract for CSLI Seminar
Date: Mon, 14 Dec 87 10:33:52 PST
From: emma
CSLI SEMINAR
Interpretation as Abduction
Jerry R. Hobbs
December 17, 1987
2:15, Redwood Hall G-19
The goal of the TACITUS project at SRI is investigate the use of
commonsense knowledge in the interpretation of discourse. We have
recently developed a new scheme for abductive inference that yields a
dramatic simplification of our characterization of what interpretation
is. I will discuss its use in solving various local pragmatics
problems, such as the resolution of reference, metonymy, and syntactic
ambiguity problems and the interpretation of compound nominals. The
scheme also suggests an elegant way to integrate syntactic and
pragmatic processing, and this will be discussed briefly.
------- End of Blind-Carbon-Copy
∂14-Dec-87 1220 ullman@navajo.stanford.edu "Non-monotonic reasoning vs. logic programming: a new perspective,"
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 14 Dec 87 12:20:14 PST
Received: by navajo.stanford.edu; Mon, 14 Dec 87 12:12:18 PST
Date: Mon, 14 Dec 87 12:12:18 PST
From: Jeff Ullman <ullman@navajo.stanford.edu>
Subject: "Non-monotonic reasoning vs. logic programming: a new perspective,"
To: nail@navajo.stanford.edu
T. C. Przymusinski, UT El Paso.
This paper, almost a survey, unifies the key notions of nonmon. reasoning:
circumscription, perfect models, "autoepistemic logic," and "default
theories," at least for the case of stratified logic programs.
I reccommend the paper to everyone, especially those who, like me,
didn't understand exactly what all those terms mean.
Only problem: the paper promises to say something about computation,
but I didn't see any algorithms that run efficiently enough
to be included in a database system. [Everything is in P, but that's
not enough, but my reconing.]
---jdu
∂15-Dec-87 1045 TOM@Score.Stanford.EDU Campus-wide power shut-down
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 15 Dec 87 10:45:50 PST
Date: Tue 15 Dec 87 10:38:13-PST
From: Thomas Dienstbier <TOM@Score.Stanford.EDU>
Subject: Campus-wide power shut-down
To: csd@Score.Stanford.EDU, staff@Score.Stanford.EDU,
faculty@Score.Stanford.EDU
Message-ID: <12358720300.33.TOM@Score.Stanford.EDU>
Once more we are having the power shut off on campus. The day of the
power shut-down will be Sunday, December 20, from 0700 thru 1600 hours or
when they are finished. Yes, this will affect Margaret Jacks Hall. We will
start to shut off machines in the computer room at around 0600 hours.
It is a good idea to "shut off" machines that are normally left on in your
offices prior to Sunday. Basically all computers, modems, and networking
devices will cease to function.
thanks
tom
-------
∂16-Dec-87 1310 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com Next Monday's PLANLUNCH -- Lincoln Wallen
Received: from WARBUCKS.AI.SRI.COM by SAIL.STANFORD.EDU with TCP; 16 Dec 87 13:09:58 PST
Received: from venice by WARBUCKS.AI.SRI.COM via SMTP with TCP; Wed,
16 Dec 87 13:03:11-PST
Received: by venice (3.2/4.16) id AA08477 for
planlunch@warbucks.ai.sri.com; Wed, 16 Dec 87 13:09:25 PST
Date: Wed, 16 Dec 87 13:09:25 PST
From: Amy Lansky <lansky@venice.ai.sri.com>
Message-Id: <8712162109.AA08477@venice>
To: csl@warbucks.ai.sri.com, planlunch@warbucks.ai.sri.com
Subject: Next Monday's PLANLUNCH -- Lincoln Wallen
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
MATRIX PROOF METHODS FOR FIRST ORDER LOGICS
Lincoln A. Wallen (LW@SALLY.UTEXAS.EDU)
Dept. of Computer Sciences, Univ. of Texas at Austin
11:00 AM, MONDAY, December 21
SRI International, Building E, Room EJ228
We present matrix-based proof methods for classical, modal, and
intuitionistic first order logics. The methods are designed to
facilitate automated proof search and, as such, represent a
comprehensive extension of resolution-style techniques to modal and
intuitionistic logics. We emphasise how the matrix methods arise from
an analysis of the structure of Gentzen sequent calculi. This
suggests a general method for obtaining efficient proof systems for
other logics of interest to Computing Science and Artificial
Intelligence.
∂16-Dec-87 1755 emma@russell.stanford.edu CSLI Calendar, December 17, 3:11
Received: from RUSSELL.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Dec 87 17:55:19 PST
Received: by russell.stanford.edu (3.2/4.7); Wed, 16 Dec 87 17:30:41 PST
Date: Wed, 16 Dec 87 17:30:41 PST
From: emma@russell.stanford.edu (Emma Pease)
To: friends@russell.stanford.edu
Subject: CSLI Calendar, December 17, 3:11
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
17 December 1987 Stanford Vol. 3, No. 11
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 17 December 1987
2:15 p.m. CSLI Seminar
Room G-19 Interpretation as Abduction
Redwood Hall Jerry R. Hobbs
(Hobbs@Warbucks.ai.sri.com)
Abstract below
3:30 p.m. Tea
Ventura Hall
--------------
ANNOUNCEMENT
There will be no seminars, TINLunches, or calendar on December 24 and
31. The next CSLI Calendar will appear on January 7, and activities
will resume on January 14.
--------------
THIS WEEK'S SEMINAR
Interpretation as Abduction
Jerry R. Hobbs
(Hobbs@warbucks.ai.sri.com)
December 17
The goal of the TACITUS project at SRI is to investigate the use of
commonsense knowledge in the interpretation of discourse. We have
recently developed a new scheme for abductive inference that yields a
dramatic simplification of our characterization of what interpretation
is. I will discuss its use in solving various local pragmatics
problems, such as the resolution of reference, metonymy, and syntactic
ambiguity problems and the interpretation of compound nominals. The
scheme also suggests an elegant way to integrate syntactic and
pragmatic processing, and this will be discussed briefly.
--------------
∂16-Dec-87 2237 LOGMTC-request Talk by Matt Kaufmann on Proof checking, Fri 18 3pm
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Dec 87 22:37:29 PST
Date: Wed 16 Dec 87 22:31:57-PST
From: Natarajan Shankar <SHANKAR@Score.Stanford.EDU>
Subject: Talk by Matt Kaufmann on Proof checking, Fri 18 3pm
To: logmtc@Sail.Stanford.EDU
Message-ID: <12359112377.19.SHANKAR@Score.Stanford.EDU>
Sorry for the short notice. Matt's a really entertaining
speaker so this should be fun.
Speaker: Matt Kaufmann (Computational Logic, Inc., Austin)
Title: Some adventures in mechanized proof checking
Date: Friday, Dec. 18
Place: to be announced
Time: 3pm
Abstract: The talk will review the Boyer-Moore logic and
discuss some extensions to both the theorem prover and the
logic. The extensions to the logic include the introduction of
quantifiers and set theory.
-------
-------
-------
∂17-Dec-87 1142 LOGMTC-request CS359 Winter 1988
Received: from CHEHALIS.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 87 11:42:33 PST
Received: by chehalis.stanford.edu (4.0/SMI-DDN)
id AA17649; Thu, 17 Dec 87 11:42:30 PST
Date: Thu, 17 Dec 87 11:42:30 PST
From: kolaitis@chehalis.stanford.edu (Phokion Kolaitis)
Message-Id: <8712171942.AA17649@chehalis.stanford.edu>
To: logmtc@sail
Subject: CS359 Winter 1988
COURSE ANNOUNCEMENT
CS359 WINTER 1988
COMPUTATIONAL COMPLEXITY AND FINITE MODEL THEORY
Time: Tu-Th 11:00-12:15, Room: to be announced
First Day of Classes: Tuesday, January 12, 1988
Instructor: Phokion G. Kolaitis, MJH 226, tel. # 3-0474 (kolaitis@chehalis)
Course Description:
The main goal of this course is to develop the connections
between complexity theory and logic on finite structures.
Topics to be covered include:
logical characterizations of complexity classes; logics on finite structures,
with emphasis on fixpoint logic and its relation to logic programming;
Ehrenfeucht-Fraisse games and their applications; 0-1 laws on finite
structures and complexity of the associated decision problems.
Course Outline:
Part I: Logical Expressibility vs. Computational Complexity
Logical characterizations of complexity classes, including:
NP = Existential Second-Order Logic.
PTIME = Fixpoint Logic on ordered finite structures.
NLOGSPACE = First-Order + Transitive Closure Operator on ordered finite
structures.
PSPACE = Second Order + Transitive Closure Operator on ordered finite
structures.
Part II: Logics on Finite Structure
The strictness of the first-order hierarchy; the collapse of the fixpoint
hierarchy at the first level; fixpoint logic and logic programming;
Ehrenfeucht-Fraisse games and their applications in separating definability
classes; applications to database theory.
Part III: 0-1 Laws and their Decision Problems
Asymptotic probabilities on finite structures; 0-1 law for first-order logic
and fixpoint logic on finite graphs; the complexity of the decision problem
for the values of the probabilities.
In recent years, research papers on these topics have appeared in STOC,
FOCS, PODS, LICS, and Structure in Complexity Theory.
∂17-Dec-87 1624 LOGMTC-request Monday Planlunch at SRI: Lincoln Wallen
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 87 16:22:15 PST
Date: Thu 17 Dec 87 16:16:35-PST
From: Natarajan Shankar <SHANKAR@Score.Stanford.EDU>
Subject: Monday Planlunch at SRI: Lincoln Wallen
To: logmtc@Sail.Stanford.EDU, csd@Score.Stanford.EDU
Message-ID: <12359306187.32.SHANKAR@Score.Stanford.EDU>
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
MATRIX PROOF METHODS FOR FIRST ORDER LOGICS
Lincoln A. Wallen (LW@SALLY.UTEXAS.EDU)
Dept. of Computer Sciences, Univ. of Texas at Austin
11:00 AM, MONDAY, December 21
SRI International, Building E, Room EJ228
We present matrix-based proof methods for classical, modal, and
intuitionistic first order logics. The methods are designed to
facilitate automated proof search and, as such, represent a
comprehensive extension of resolution-style techniques to modal and
intuitionistic logics. We emphasise how the matrix methods arise from
an analysis of the structure of Gentzen sequent calculi. This
suggests a general method for obtaining efficient proof systems for
other logics of interest to Computing Science and Artificial
Intelligence.
-------
-------
∂17-Dec-87 1624 LOGMTC-request Matt Kaufmann's talk is in MJH301, Fri 18, 3pm.
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 87 16:24:44 PST
Date: Thu 17 Dec 87 16:19:01-PST
From: Natarajan Shankar <SHANKAR@Score.Stanford.EDU>
Subject: Matt Kaufmann's talk is in MJH301, Fri 18, 3pm.
To: logmtc@Sail.Stanford.EDU, csd@Score.Stanford.EDU,
galbiati@rocky.Stanford.EDU
Message-ID: <12359306630.32.SHANKAR@Score.Stanford.EDU>
Note the location (MJH 301) which was missing from the previous
announcement.
The title is, `Some adventures in mechanized proof checking'.
-------
∂18-Dec-87 0917 @Sushi.Stanford.EDU:PAPA@Score.Stanford.EDU Re: Complexity of optimal addition chains
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 18 Dec 87 09:16:54 PST
Received: from Score.Stanford.EDU by Sushi.Stanford.EDU with TCP; Fri 18 Dec 87 09:09:44-PST
Date: Fri 18 Dec 87 09:09:52-PST
From: C. Papadimitriou <PAPA@Score.Stanford.EDU>
Subject: Re: Complexity of optimal addition chains
To: THEORYNT%NDSUVM1.BITNET@Forsythe.Stanford.EDU,
VICTOR%YKTVMZ.BITNET@Forsythe.Stanford.EDU
cc: AFLB.TN@Sushi.Stanford.EDU
In-Reply-To: Message from ""Victor S. Miller" <VICTOR%YKTVMZ.BITNET@forsythe.stanford.edu>" of Tue 8 Dec 87 12:18:48-PST
Message-ID: <12359490651.32.PAPA@Score.Stanford.EDU>
Finding the best addition chain has been conjectured to be NP-complete.
As I recall, Ravi Sethi and co-authors have shown that finding the best
addition chain for several numbers (to be computed together) is NP-complete.
---CHP
-------
∂18-Dec-87 1146 SLOAN@Score.Stanford.EDU Reminder
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 18 Dec 87 11:46:16 PST
Date: Fri 18 Dec 87 11:37:37-PST
From: Yvette Sloan <SLOAN@Score.Stanford.EDU>
Subject: Reminder
To: Faculty@Score.Stanford.EDU, Staff@Score.Stanford.EDU
Message-ID: <12359517546.29.SLOAN@Score.Stanford.EDU>
Reminder: The Computer Science Christmas party for Faculty and Staff is today
at 3:30 in MJH 146. See you there!!
-------
∂18-Dec-87 1244 @Score.Stanford.EDU:cheriton@pescadero.stanford.edu Lunch Jan. 5th: CSD Boundary Value/Problems
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 18 Dec 87 12:44:50 PST
Received: from pescadero.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 18 Dec 87 12:37:52-PST
Received: by pescadero.stanford.edu; Fri, 18 Dec 87 12:42:43 PST
Date: Fri, 18 Dec 87 12:42:43 PST
From: David Cheriton <cheriton@pescadero.stanford.edu>
To: faculty@score.stanford.edu
Subject: Lunch Jan. 5th: CSD Boundary Value/Problems
I have proposed a discussion for Jan. 5th faculty lunch to discuss
the problems and values associated with defining boundaries to what
we consider reasonably part of Computer Science and the CS Department.
This is prompted in part by the discussion of Symbolic Systems program
and also by proposed courtesy apointments and joint-listings of courses.
Please give it some thought.
David C.
∂18-Dec-87 1331 TAJNAI@Score.Stanford.EDU Merry Christmas from the Computer Forum
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 18 Dec 87 13:31:44 PST
Date: Fri 18 Dec 87 13:16:53-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Merry Christmas from the Computer Forum
To: csd.list@Score.Stanford.EDU, csl-everyone@Sierra.Stanford.EDU
Message-ID: <12359535617.18.TAJNAI@Score.Stanford.EDU>
BEST WISHES FOR THE HOLIDAY SEASON
*
*|*
*/*|*\*
*/*/*|*\*\*
*/*/*/*|*\*\*\*
*/*/*/*/*|*\*\*\*\*
*/*/*/*/*/*|*\*\*\*\*\*
*/*/*/*/*/*/*|*\*\*\*\*\*\*
*/*/*/*/*/*/*/*|*\*\*\*\*\*\*\*
*/*/*/*/*/*/*/*/*|*\*\*\*\*\*\*\*\*
*/*/*/*/*/*/*/*/*/*|*\*\*\*\*\*\*\*\*\*
*/*/*/*/*/*/*/*/*/*/*|*\*\*\*\*\*\*\*\*\*\*
*/*/*/*/*/*/*/*/*/*/*/*|*\*\*\*\*\*\*\*\*\*\*\*
*/*/*/*/*/*/*/*/*/*/*/*/*|*\*\*\*\*\*\*\*\*\*\*\*\*
*/*/*/*/*/*/*/*/*/*/*/*/*/*|*\*\*\*\*\*\*\*\*\*\*\*\*\*
|||
|||
+++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++
With warm greetings and
renewed hopes for
peace, good health and happiness
in the coming year.
The Stanford University Computer Forum
Carolyn Tajnai, Bonnie Hiller,
Katie Mac Millen (who is leaving) and Elizabeth Buss (who just arrived)
-------
∂18-Dec-87 1503 CBARSALOU@Score.Stanford.EDU Elevator problem
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 18 Dec 87 15:03:30 PST
Date: Fri 18 Dec 87 14:48:11-PST
From: Caroline Barsalou <CBARSALOU@Score.Stanford.EDU>
Subject: Elevator problem
To: csd-list@Score.Stanford.EDU
Message-ID: <12359552237.42.CBARSALOU@Score.Stanford.EDU>
I spoke with a person who is maintaining the elevator in Jacks the
other day, and he asked me to post the following message:
During the past six months, the doors of the elevator sometimes slammed
very violently (it actually happened to me, it's pretty scary). So far, no
injuries have been reported.
The maintenance checked the system and everything seems OK with the elevator
itself. The cause might be some power spurts occuring in Jacks.
If you experience such an adventure, please note the following and report it
to Thea, at the receptionnist desk. The maintenance company will check messages
regularly.
* date
* time
* which door(s) slammed (inside/outside door, left or right, or both at the
same time..)
Thanks for your cooperation and ride safely!
Caroline
-------
∂21-Dec-87 1935 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com Reminder -- Monday Planlunch -- note ROOM CHANGE
Received: from WARBUCKS.AI.SRI.COM by SAIL.STANFORD.EDU with TCP; 21 Dec 87 19:35:13 PST
Received: from venice by WARBUCKS.AI.SRI.COM via SMTP with TCP; Sun,
20 Dec 87 22:18:02-PST
Received: by venice (3.2/4.16) id AA11240 for
planlunch_reminder@WARBUCKS.ai.sri.com; Sun, 20 Dec 87 22:19:51 PST
Date: Sun 20 Dec 87 22:19:48-PST
From: Amy Lansky <LANSKY@venice.ai.sri.com>
Subject: Reminder -- Monday Planlunch -- note ROOM CHANGE
To: planlunch_reminder@WARBUCKS.ai.sri.com
Message-Id: <567065988.0.LANSKY@VENICE.ARPA>
Mail-System-Version: <SUN-MM(213)+TOPSLIB(128)@VENICE.ARPA>
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
MATRIX PROOF METHODS FOR FIRST ORDER LOGICS
Lincoln A. Wallen (LW@SALLY.UTEXAS.EDU)
Dept. of Computer Sciences, Univ. of Texas at Austin
11:00 AM, MONDAY, December 21
SRI International, Building E, Room EK242
We present matrix-based proof methods for classical, modal, and
intuitionistic first order logics. The methods are designed to
facilitate automated proof search and, as such, represent a
comprehensive extension of resolution-style techniques to modal and
intuitionistic logics. We emphasise how the matrix methods arise from
an analysis of the structure of Gentzen sequent calculi. This
suggests a general method for obtaining efficient proof systems for
other logics of interest to Computing Science and Artificial
Intelligence.
-------
∂21-Dec-87 1938 @Score.Stanford.EDU:golub@golubsun.cs.umd.edu Kent Curtis
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 Dec 87 19:38:26 PST
Received: from mimsy.umd.edu by SCORE.STANFORD.EDU with TCP; Mon 21 Dec 87 09:30:45-PST
Received: from golubsun.cs.umd.edu by mimsy.umd.edu (5.58/4.7)
id AA09910; Mon, 21 Dec 87 10:44:33 EST
Received: by golubsun.cs.umd.edu (5.54/3.14)
id AA00288; Mon, 21 Dec 87 10:44:08 EST
Date: Mon, 21 Dec 87 10:44:08 EST
From: golub@golubsun.cs.umd.edu (Gene Golub)
Return-Path: <golub@golubsun.cs.umd.edu>
Message-Id: <8712211544.AA00288@golubsun.cs.umd.edu>
To: faculty@score.stanford.edu
Subject: Kent Curtis
Kent Curtis who was director of the division of computer and
computation research at NSF died of cancer on Dec 17. He was a
thoughtful and kindly person and committed himself completely to the
development of computer science.
Gene Golub
∂21-Dec-87 1940 TAJNAI@Score.Stanford.EDU Computer Forum 20th Annual Meeting
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 Dec 87 19:40:25 PST
Date: Mon 21 Dec 87 10:01:01-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Computer Forum 20th Annual Meeting
To: faculty@Score.Stanford.EDU
Message-ID: <12360286392.28.TAJNAI@Score.Stanford.EDU>
Craig Cornelius is Chairman of the poster/demo session for the
meeting in Feb. It is scheduled for Wednesday, Feb. 10 from 1:30 to
4:00. Craig and I have sent several messages to the students, but
the response has been very disappointing.
The Poster Session was my idea, and I still think it is a good one --
it offers an opportunity for students to present their work at the
meeting. Normally only the senior level PHD students have this
opportunity. A group could also offer a demo.
The following is a recent message that Craig sent to
the students. It would be very much appreciated if you would point
out to your advisees this opportunity and encourage them to participate.
********************
This is a reminder about your chance to participate in the 20th Annual
Meeting of the Stanford Computer Forum, which will be held February 9
- 11, 1988 at Stanford. The program includes a student poster and
demonstration session for 2-1/2 hours on Wednesday afternoon, Feb. 10.
On behalf of the Forum Committee, I invite all PhD, MSCS, and MSAI
students to present their research at this session.
The poster session is an exciting opportunity for you to share your
research, learn about other work in our projects, and present your
ideas to an interested audience. There are also facilities for a few
demonstrations at the poster session, too.
The format is informal: Posters are displayed around a large room (in
CERAS Hall Lobby). At any given time, about 1/2 of the posters are
accompanied by a presenter, who answers questions and explains the
research to any and all who stop by.
You should work out the topic and format of your poster in
consultation with your research director. The material should be
aimed at an intelligent audience that is generally knowledgable about
computers, but not necessarily acquainted with the particular problem
and project you are presenting.
As "czar" of this activity, I need to know the following from
participants: (a) your name, (b) your topic, (c) your advisor,
definitely by mid-January. I'd also appreciate hearing from those who
expressed an interest earlier in the quarter.
The room size for this poster session is limited, and it is necessary
to reserve space by January 15 if you intend to participate. If you'd
like to present a demonstration using your computer equipment, please
let me know VERY SOON, since setting up demos will require special
arrangements.
Of course, please feel free to contact me with questions and
suggestions. I have several excellent posters prepared by KSL
students that you may examine for ideas on presentation.
Craig Cornelius
"Poster Czar" and Research Associate
Knowledge Systems Laboratory
725-3860 Cornelius@Sumex
*****************************************
Your help is needed!
Carolyn
-------
∂22-Dec-87 1351 TAJNAI@Score.Stanford.EDU [Ted Shortliffe <Shortliffe@SUMEX-AIM.Stanford.EDU>: retreat posters]
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 22 Dec 87 13:51:07 PST
Date: Tue 22 Dec 87 13:45:24-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: [Ted Shortliffe <Shortliffe@SUMEX-AIM.Stanford.EDU>: retreat posters]
To: faculty@Score.Stanford.EDU
Message-ID: <12360589386.47.TAJNAI@Score.Stanford.EDU>
Ted Shortliffe sent the following message to his advisees. Marty
Tenenbaum is going to have some ME/CS students display posters.
Would appreciate your approaching your advisees.
Carolyn
---------------
Return-Path: <SHORTLIFFE@SUMEX-AIM.Stanford.EDU>
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 22 Dec 87 11:10:22-PST
Date: Tue, 22 Dec 87 11:13:27 PST
From: Ted Shortliffe <Shortliffe@SUMEX-AIM.Stanford.EDU>
Subject: retreat posters
To: mcs-students@SUMEX-AIM.Stanford.EDU
cc: cornELIUS@SUMEX-AIM.Stanford.EDU, fagan@SUMEX-AIM.Stanford.EDU,
cooper@SUMEX-AIM.Stanford.EDU
Medical School Office Building X-215; (415) 723-6979
Message-ID: <12360561722.25.SHORTLIFFE@SUMEX-AIM.Stanford.EDU>
As you probably know, Craig Cornelius is organizing a
poster session for the CS Computer Forum in February. Although
it is purely voluntary, if some of you would like to display
your retreat posters (or make a new one?) and use them as the
focus for discussion with forum members, please let Craig know
asap. The CS Forum now includes a large number of corporate
members from around the country, and this is an excellent way
to provide exposure to your work.
Ted
-------
-------
∂22-Dec-87 1437 GILBERTSON@Score.Stanford.EDU Holiday Schedule
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 22 Dec 87 14:37:50 PST
Date: Tue 22 Dec 87 14:26:35-PST
From: Edith Gilbertson <GILBERTSON@Score.Stanford.EDU>
Subject: Holiday Schedule
To: CSD-List@Score.Stanford.EDU
Message-ID: <12360596883.18.GILBERTSON@Score.Stanford.EDU>
Dear Folks in Computer Science -
To clarify the Holiday time-off schedule, the CSD will be closed all
day Thursday, Dec 24 and all day Friday, Dec 25 this week.
Next week we will close at noon on Thursday, Dec 31 and be closed all
day Friday, Jan 1.
Have a Merry MERRY Four-Day-Weekend Holiday (otherwise known as *Christmas*
for many), and a Joyous JOYOUS Three-and-one-half-Day Weekend Holiday
(otherwise known as *New Years* for "most").
↑
*
/*!*\
/*/!\*\
x
-Edie
-------
∂23-Dec-87 0128 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #98
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Dec 87 01:28:02 PST
Date: Tue 22 Dec 1987 05:52-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #98
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Wednesday, 23 Dec 1987 Volume 5 : Issue 98
Today's Topics:
Query - Inductive Consequence,
Announcement - Call for Papers,
Theory - Complexity,
LP Library - Reviews
----------------------------------------------------------------------
Date: 16 Dec 87 00:14:00 GMT
From: reddy@b.cs.uiuc.edu
Subject: Inductive consequence
I am looking for pointers to any work in logic programming dealing
with inductive consequence, where the notion of inductive consequence
is defined by one of the following:
. S is an inductive consequence of A if every ground instance of S
follows from A.
. S is an inductive consequence of A if the least model of S is the
same as the least model of A union S.
. S is an inductive consequence of A if A union S is consistent.
I think I saw some work by Kowalski refering to one of these
definitons, but I can't place it.
-- Uday Reddy
------------------------------
Date: Mon, 21 Dec 87 14:27:47 -0800
From: Richard Nelson <nelson@ICS.UCI.EDU>
Subject: Call for Papers
ICEBOL3
April 21-22, 1988 Dakota State College
Madison, SD 57042
ICEBOL3, the International Conference on Symbolic and
Logical Computing, is designed for teachers, scholars, and
programmers who want to meet to exchange ideas about
non-numeric computing. In addition to a focus on SNOBOL,
SPITBOL, and Icon, ICEBOL3 will feature introductory and
technical presentations on other dangerously powerful
computer languages such as Prolog and LISP, as well as on
applications of BASIC, Pascal, and FORTRAN for processing
strings of characters. Topics of discussion will include
artificial intelligence, expert systems, desk-top
publishing, and a wide range of analyses of texts in English
and other natural languages. Parallel tracks of concurrent
sessions are planned: some for experienced computer users
and others for interested novices. Both mainframe and
microcomputer applications will be discussed.
ICEBOL's coffee breaks, social hours, lunches, and
banquet will provide a series of opportunities for
participants to meet and informally exchange information.
Sessions will be scheduled for "birds of a feather" to
discuss common interests (for example, BASIC users group,
implementations of SNOBOL, computer generated poetry).
Call For Papers
Abstracts (minimum of 250 words) or full texts of
papers to be read at ICEBOL3 are invited on any application
of non-numeric programming. Planned sessions include the
following:
artificial intelligence
expert systems
natural language processing
analysis of literary texts (including bibliography,
concordance, and index preparation)
linguistic and lexical analysis (including parsing and
machine translation)
preparation of text for electronic publishing
computer assisted instruction
grammar and style checkers
music analysis.
Papers must be in English and should not exceed twenty
minutes reading time. Abstracts and papers should be
received by January 15, 1988. Notification of acceptance
will follow promptly. Papers will be published in ICEBOL3
Proceedings.
Presentations at previous ICEBOL conferences were made
by Susan Hockey (Oxford), Ralph Griswold (Arizona), James
Gimpel (Lehigh), Mark Emmer (Catspaw, Inc.), Robert Dewar
(New York University), and many others. Copies of ICEBOL 86
Proceedings are available.
ICEBOL3 is sponsored by
The Division of Liberal Arts
and
The Business and Education Institute
of
DAKOTA STATE COLLEGE
Madison, South Dakota
For Further Information
All correspondence including abstracts and papers as
well as requests for registration materials should be sent
to:
Eric Johnson
ICEBOL Director
114 Beadle Hall
Dakota State College
Madison, SD 57042 U.S.A.
(605) 256-5270
Inquiries, abstracts, and correspondence may also be
sent via electronic mail to:
ERIC @ SDNET (BITNET)
------------------------------
Date: Wed, 16 Dec 87 03:00:22 PST
From: quintus!ok@Sun.COM (Richard A. O'Keefe)
Subject: complexity
An alert reader jumped on me for distinguishing between
O(N.log(2,N)) and O(N.log(200,N)). Big-Oh notation is of
course defined to ignore constant factors. Mea culpa.
He went on to say that you cannot take constant factors
into account in asymptotic arithmetic. This happens to
be true for this particular notation, but it is not true
in general.
The notation I want is
f(N) = <o>(g(N))
if lim N->infinity f(N)/g(N) = 1. There is a notation for
this "equation": one can write
f(N) ~ g(N)
but I'd like something I can write in an expression just as
you can use big-O or little-o or big-Omega or little-omega.
What should I write for <o>?
In my reply to this alert reader, I went on to say that not
only is it possible to take constant factors into account,
it is irresponsible not to do so. He misunderstood this.
YES if you want to know the TIME that an algorithm will
take, that is implementation dependent, and big-Oh is as
good as you can get. BUT operation COUNTS are not
implementation dependent, and ignoring constant factors
there is disastrous. We have seen that ignoring the
constant factor in the number of comparisons done by a
sorting routine has led a lot of people to use quick-sort
(30% slower than merge sort across a wide range of machines
and languages).
To return to the current example (random permutations),
the logarithmic permutation generators generate precisely
<o>(N.ceil(log(T,N)))
random numbers, and do as many conses, whereas the
linear-expected time permutation generator for unbounded-
term Prologs generates
<o>(1.58N)
random numbers and
<o>(3.16N)
calls to arg/3, while a more complicated version generates
<o>(1.06N)
random numbers but does
<o>(3.50N)
calls to arg/3 (more calls to arg because the terms it builds
are twice as long, so reading off the result takes twice as
many calls). In order to compare these two versions, you have
to compare the constant factors!
It seems obvious that any algorithm which operates by keeping
a pool of numbers which have (already / not yet) been generated
and consults them each time it generates a new number must take
O(N.log(T,N)) time in a bounded-term language (this time I do
mean big-Oh), but it is not clear that some method of generating
numbers in batches might not exist.
I have been asked to explain how the partition step in the
quicksort-like random permutation generator works. See Knuth
Vol 2, Section 3.4.2, Algorithm S.
I really would like to hear of some answers for this problem,
not more questions.
------------------------------
Date: Tue, 15 Dec 87 23:34:15 PST
From: quintus!ok@Sun.COM (Richard A. O'Keefe)
Subject: Book
A couple of days ago I bought a copy of
"Relational Database -- Selected Writings"
by C. J. Date
Addison-Wesley 1986, ISBN 0-201-14196-5
(US$34.95 + tax)
One thing which makes me angry is elementary Prolog courses
where the author has obviously never troubled to read the
data base literature, doesn't know the term "null value",
doesn't understand the problems, and has given bad advice.
(For example, in one course I saw the author use anonymous
variables when he intended existential nulls, and in another
the authors in all seriousness suggested that it was a good
idea to put 'na' in tables -- these are REAL examples that
students were paying a fair chunk of money to attend.)
This book should be required reading for anyone presenting such
courses. (I hope Mr J.M. and Mr M.E. are reading this...) It is
not necessary for them to teach this material, but it IS
important that people teaching Prolog should UNDERSTAND it.
Nearly everything in the book is good. I'll just mention two of
the chapters.
Chapter 15 of this book explains some of the problems with null
values (I hadn't realised that the outer natural join isn't a
projection of the outer equi-join until I read it), and he
strongly recommends against the use of null values. (Remember:
he is writing about SQL, not Prolog!) Most refreshing. I have
been telling people they shouldn't use null values in Prolog
(because it hasn't got them), now I have something I can point
to which explains why null values are ALWAYS a bad idea.
Chapter 19 is really good value: it is all about working out
how to represent a problem in relational terms. You should
probably read chapter 3 (Why Every Relation Should Have Exactly
One Primary Key) and chapter 4 (Referential Integrity) first.
There isn't anything staggeringly new there; anyone who has read
Codd's paper on RM/T will recognise some of it, and it has a lot
in common with the entity/relationship approach. But this is a
straightforward presentation based on the plain old relational
model.
One quotation from this chapter:
One of the advantages frequently claimed for relational
systems--and I believe fairly--is precisely that database
design is easier than it is in a nonrelational system.
And just to show how simple it is, here is a paper of
some 50 or so closely printed pages to explain how it
is done. . . . (:-)
Try to talk your library into getting a copy.
[Presumably it already has Kent's "Data and Reality".]
------------------------------
Date: Wed, 16 Dec 87 22:35:55 PST
From: quintus!ok@Sun.COM (Richard A. O'Keefe)
Subject: New Book
The book by Warren & Maier is now in the bookshops.
Computing with Logic: logic programming with Prolog
David Maier/David S. Warren
The Benjamin/Cummings Publishing Co. Inc.
ISBN 0-8053-6681-4
US$30.35 at Stacey's
These two authors are uniquely well qualified to write a
book presenting Prolog from a data base perspective; the
need has long been felt for something which would explain
how to design a Prolog program using the data base so
that it makes sense.
Unfortunately, that's not the book they chose to write.
The preface says
This text is appropriate for a senior or first-year
graduate course on logic programming.
It concentrates on the formal semantics of logic
programs [1], automatic theorem proving techniques [2],
and efficient implementation of logic languages [3].
It is also an excellent reference for the computer
professional wishing to do self-study on the
fundamentals of logic programming [4]. We have
included numerous examples to illustrate all the
major concepts and results. No other text deals with
implementation in as much detail [5].
[1] I only bought the book this morning, and have only skimmed
most of it. But I couldn't find one line that I recognised
as a formal semantics of anything. If, like me, you think
that "formal semantics" is the Scott/Strachey, Milner,
Jones, &c sort of thing (like Kahn's (?) formal semantics
for Prolog that a partial executor was based on), you'll
find none of that here. You WILL find a succession of
interpreters in Pascal for successively larger sublanguages
of Prolog. Most readers will probably find the absence of
real formal semantics a virtue rather than otherwise.
[2] "Automatic theorem proving techniques" means Input Resolution.
If you want to know about automatic theorem proving techniques,
buy another book.
Automated Reasoning: introduction and applications
Wos, Overbeek, Lusk, & Boyle
Prentice-Hall
ISBN 0-13-054446-9
would be my choice.
[3] Not "logic languages". You'll find nothing to help you if
you want a forward chaining logic language, or coroutining,
or anything else but plain Prolog. It's none the worse for
that, but do remember that this IS a >Prolog< book, not a
logic language book. (The key idea behind Turbot Prolog
-- if it isn't a dead fish, why does it smell bad? --
is not discussed in this book, for example.)
[4] Depends on what you mean by "the fundamentals". If you want
to know what Prolog does and how a typical Prolog implementation
does it, this is a pretty good book. If you want to know why
anybody would care, what is the theory behind all this, how to
show that a Prolog system is (or is not) correct, or how Prolog
ties in with other areas of CS such as relational data base
theory, you'll need several other books instead.
[5] I haven't got a copy, but doesn't the Kluzniak et al book
contain a complete Prolog interpreter in Pascal?
There is >one< section in this book (11.8) which describes the
WAM. It suffers from the same defect as the WAM tutorial put
together at ANL, namely that they've changed all the register
names and most of the instruction names (they even have a new
name "WPE" for the WAM as a whole). If you want to understand
the WAM, get a copy of David H.D. Warren's original paper on it,
which is much clearer than most of the "expositions" since.
All of the really hard aspects of Prolog implementation have
been left out. A major omission is any discussion of
garbage collection (well, it's not in the index, table of
contents, nor in any of the running heads).
I bought this book because I work for a Prolog company, feel I
ought to know what the good Prolog books are, wanted D.S.Warren
to get some royalties, and was hoping for great things from this
book. I'm afraid it's not all that clear to me why anyone else
would buy it.
Let me say a few good things about it.
The book follows a coherent plan, interleaving the presentation
of a succession of sublanguages and their interpreters so that
the reader will end up with a pretty fair understanding of how
(some) Prolog systems and compilers work.
This book contains fewer errors than any of the other Prolog
books I've seen. For example, reading this book will leave
you with less practical grip of Prolog than reading Bratko's,
but considerably fewer misconceptions and bad habits.
In the sections that I've checked, the authors have used
technical terms clearly and consistently.
I don't expect anyone to come to any harm from reading this book,
which is more than I can say of most Prolog texts. This is a well
written book; I'm just disappointed that such good soldiers
weren't fighting where the line was thinnest.
How does this book rate on the Touchstone (all solutions predicates)?
The topic is not treated in depth, but what they do say about
setof/3 and bagof/3 is correct. They even present them in the
right order: setof/3 first, and then bagof/3 as a variant of setof/3.
They present code for findall/3. Now the description of retract/1
in the text is quite correct, but the code for findall/3 is wrong.
They write (using long variable names, good point):
findall(T, G, L) :-
assert_answers(T, G),
collect_answers(X),
L = X.
assert_answers(T, G) :-
call(G),
assertz(answer_fact(T)),
fail.
assert_answers(_, _).
collect_answers([T|Ts]) :-
retract(answer_fact(T)),
!,
collect_answers(Ts).
collect_answers([]).
There is so much about this that is right, so many errors they have
avoided. Pity nested findalls won't work...
By the time they have worked up to full Prolog, you should stop
imitating their examples. Their aim is quite explicitly clarity
rather than efficiency, and several of the examples will leave a
lot of choice points around. (For example, the code they give
for testing whether a term is ground uses functor/3 and arg/3
as it should, but letting N be the number of function and
constant symbol occurrences in the term under consideration,
it will leave N choice points behind.) You could do worse
than imitate their layout, however (you could imitate Bratko's
layout; that would be much worse).
------------------------------
End of PROLOG Digest
********************
∂23-Dec-87 1028 barwise@alan.stanford.edu Courses for next quarter
Received: from RUSSELL.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Dec 87 10:28:13 PST
Received: from alan.stanford.edu by russell.stanford.edu (3.2/4.7); Wed, 23 Dec 87 10:30:08 PST
Received: from localhost by alan.stanford.edu (3.2/4.7); Wed, 23 Dec 87 10:30:44 PST
To: ssp-students@alan.stanford.edu
Cc: ssp-faculty@alan.stanford.edu
Subject: Courses for next quarter
Date: Wed, 23 Dec 87 10:30:43 PST
From: barwise@alan.stanford.edu
In planning your courses for next quarter, don't forget that there is
one option that is not in the catalogue, namely SSP 195, Microcomputer
Programming Project. You can work with any SSP faculty, consulting or
regular, and you may be able to fit it in your concentration.
∂23-Dec-87 1147 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu PARCELLA '88
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Dec 87 11:47:50 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Wed 23 Dec 87 11:41:57-PST
Received: by lindy.stanford.edu; Wed, 23 Dec 87 11:43:54 PST
Received: by Forsythe.Stanford.EDU; Wed, 23 Dec 87 11:45:12 PST
Received: by BYUADMIN (Mailer X1.25) id 8387; Wed, 23 Dec 87 12:40:58 MST
Date: Wed, 23 Dec 87 13:17:45 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
JORG SACK <SACK%CARLETON.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMZ
From: JORG SACK <SACK%CARLETON.BITNET@forsythe.stanford.edu>
Subject: PARCELLA '88
To: Local Distribution <aflb.tn@sushi.stanford.edu>
-------------------------------------------------------------------------
FIRST ANNOUNCEMENT
AND CALL FOR PAPERS
PARCELLA ' 88
The IV. International Workshop on
PARALLEL PROCESSING BY
CELLULAR AUTOMATA AND ARRAYS
Organized by the Central Institute of Cybernetics and Information
Processes of the Academy of Sciences of the G.D.R. and the
Research Group on Automata Theory of the Hungarian Academy of Sciences
to be held in BERLIN, G.D.R.
during OCTOBER 17-21, 1988
Topics of main interest are focused on: ALL PROBLEMS OF REGULAR
PARALLEL AND SYSTOLIC ARCHITECTURES AND ALGORITHMS
mainly:
Basic Problems & General Taxonomy
Mathematical Models & Theoretical Foundations
Architectures & Distributed Data Structures
Concurrent Algorithms & Concurrent Languages
Programming & Basic Tools of Application
Design, Design Methodology & Implementation
Results & Projects - Numerical Applications
Image Processing & Computational Geometry
Results & Projects - Nonnumerical Applications
Cellular Automata & Dynamical Systems
Other Parallel Computing Structures implemented in or
compared with Cellular Machines and/or Arrays
Superarraycomputing
Cellware & Cellprocessing
ORGANIZERS AND CHAIRMEN: T. Legendi (Szeged) G. Wolf (Berlin)
(founder) (local chairman)
SCIENTIFIC ADVISER: V. Kempe (Berlin)
INTERNATIONAL PROGRAM COMMITTEE (non finally fixed list):
A. Albrecht, Berlin D. Parkinson, London
W. Haendler, Erlangen J. Toth, Szeged
C. Jesshope, Southampton U. Schendel, Berlin-West
A. Jugel, Dresden R. Vollmar, Braunschweig
N. Kasabov, Sofia W. Wilhelmi, Berlin
E. Katona, Szeged G. Wunsch, Dresden
S. Levialdi, Rome C.K. Yap, New York
J. Miklosko, Bratislava J.-R. Sack, Ottawa
LECTURES: Prospective contributors are invited to submit 5 copies
of the abstract of their lecture (maximum 1 page) to
T. Legendi
Research Group on Automata Theory
H - 6720 Szeged
Somogyi u. 7
Hungary
telex: 82 213 mta h
phone: (36)-62-21864
Deadline for submission of abstracts
February 29 th (with paper)
April 30 th (oral presentation only)
Notification of acceptance or rejection of contributed lectures
May 3l st
PROCEEDINGS AND PAPERS:
It is intended to publish the papers of the workshop in the
proceedings, available during the workshop.
Full papers on special typing sheets and 5 copies should
be mailed to
Parcella Conference Office
Central Institute of Cybernetics
and Information Processes
Kurstrasse 33
P.O.B. 1298
Berlin1086
G.D.R.
Please use special sheets only mailed by conference office on your claim. Deadl
ine for submission of full papers: February 29 th
Notification of acceptance or rejection: May 31 st
NOTE PARALLEL PROCEDURES FOR LECTURES AND PAPERS PLEASE!
PLACE: Berlin
TIME: Monday 17th to Friday 21st October 1988
Tuesday, Wednesday and Thursday are full day conference days.
Monday and Friday are free for computer demos, poster
sessions, consultations, registration a. s. o.
FEE (including the Proceedings):
400,-M (DM) till July 30th 1988; 450,-M (DM) later
for speakers 200,-M (DM) till July 30th 1988; 250,-M (DM) later
Participants from Western countries have to pay in their own
currencies.
LANGUAGE: Conference language is English
REGISTRATION: Deadline for submission registration form (below) February 29th to
Parcella Conference Office
Central Institute of Cybernetics
and Information Processes
Mrs. Boettcher (Head of Organizing Staff)
Kurstrasse 33
P.O.B. 1298
Berlin1086
G.D.R.
CONFERENCE OFFICE can be contacted additionally by
phone: (37)-2-2072264 (head of organizing staff)
(37)-2-2072313 (local chairman)
telex: 11 45 36 zki dd
ADDITIONAL EVENTS: Suggestions for computer demos, exhibitions, panel discussio
ns should be transmitted to the chairmen or conference office resp. Conference
party and post conference trip are under preparation.
______________________________________________________
IV. INTERNATIONAL WORKSHOP
PARCELLA 88
Berlin (GDR), October 17-21, 1988
______________________________________________________
Surname:
______________________________________________________
First Name:
______________________________________________________
Academic title:
______________________________________________________
Title of the paper:
______________________________________________________
Institution (address):
______________________________________________________
Country:
______________________________________________________
Please book:
I plan to attend Single room from ..... to .....
I plan to give a lecture Double room from .... to .....
oral representation No booking
written contribution
Date: Signature:
∂23-Dec-87 1548 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Solution to 2-D search problem
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Dec 87 15:48:40 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Wed 23 Dec 87 15:43:15-PST
Received: by lindy.stanford.edu; Wed, 23 Dec 87 15:45:17 PST
Received: by Forsythe.Stanford.EDU; Wed, 23 Dec 87 15:46:19 PST
Received: by BYUADMIN (Mailer X1.25) id 0198; Wed, 23 Dec 87 16:45:51 MST
Date: Wed, 23 Dec 87 17:40:45 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Das Gautam <gautam%cs.wisc.edu@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Das Gautam <gautam%cs.wisc.edu@forsythe.stanford.edu>
Subject: Solution to 2-D search problem
To: Local Distribution <aflb.tn@sushi.stanford.edu>
I am looking for solutions to the following 2-d search problem:
Given k points on a plane. A query specifies a triangle, with one side
parallel to the x axis. The output of the query should be the point
within the triangle with the largest y coordinate.
I am also interested in the "rectilinear version", where each query
specifies a rectangle, with its sides parallel to the axes.
I would like to see solutions which involve O(klogk) preprocessing time,
and O(logk) queryprocessing time. However any solution which involves
subquadratic preprocessing and sublinear queryprocessing would also be
useful.
∂23-Dec-87 1630 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu ACM Publication policy
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Dec 87 16:30:41 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Wed 23 Dec 87 16:24:56-PST
Received: by lindy.stanford.edu; Wed, 23 Dec 87 16:26:53 PST
Received: by Forsythe.Stanford.EDU; Wed, 23 Dec 87 16:27:54 PST
Received: by BYUADMIN (Mailer X1.25) id 0483; Wed, 23 Dec 87 17:27:19 MST
Date: Wed, 23 Dec 87 17:44:23 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Barbara Simons <simons@ibm.com>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Barbara Simons <simons@ibm.com>
Subject: ACM Publication policy
To: Local Distribution <aflb.tn@sushi.stanford.edu>
To the theory community:
I received the following letter from Peter Denning. I am sending it
out over theorynet because I have heard various people express concern
about ACM publication policy. The revisions implied by the letter
should at least make practice a closer match to policy.
Barbara Simons
____________________________
As a followup to an earlier general mailing, I am writing to remind
you of the policy change about republishing papers that have (or will
soon) appear in a conference proceedings. The core of the policy is
that a paper may be republished in a journal provided that the editor
determines there is significant additional benefit from doing so.
I am enclosing a copy of the full policy statement for your information.
(Note: if you need a copy, you can contact Barbara Simons at
408:927-1785, simons@ibm.com).
EDITORS: You may now feel free to consider papers that have (or will)
appear in a conference proceedings, whether from an ACM SIG conference
or from some other conference. The fact of publication in a conference
proceedings is not an automatic ground to refuse to consider the paper.
You should request your reviewers to advise you on whether significant
additional benefit would be gained by republishing. If you accept such
a paper, be sure that the proper cross-reference to the conference
proceedings appears on the first page. If the paper in question
appeared in a conference proceeding that does not have an ACM copyright,
it is the author's responsibility (under other ACM policies) to obtain
the appropriate copyright release.
SIG CHAIRS: You may now feel free to include in your proceedings all
papers accepted by your program committees. You need not withhold
papers that are accepted (or under consideration for) a journal.
You need not insist that the authors of the "best" papers publish abstracts
only in order to protect their right to submit the paper to a journal.
Please advise your program committee chairs of this change and request
them to be sure that the proper cross-reference to the journal appears
on the first page of such papers.
Please note that this is an ACM policy that affects ACM journals. Nothing
has been negotiated with any other society with respect to
republication of ACM materials in their journals.
∂23-Dec-87 2035 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu SIGACT News Educational Forum
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Dec 87 20:35:40 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Wed 23 Dec 87 20:30:16-PST
Received: by lindy.stanford.edu; Wed, 23 Dec 87 20:32:20 PST
Received: by Forsythe.Stanford.EDU; Wed, 23 Dec 87 20:33:47 PST
Received: by BYUADMIN (Mailer X1.25) id 1657; Wed, 23 Dec 87 21:32:35 MST
Date: Wed, 23 Dec 87 22:25:24 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
dsj%research.att.com@relay.cs.net
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: dsj%research.att.com@relay.cs.net
Subject: SIGACT News Educational Forum
To: Local Distribution <aflb.tn@sushi.stanford.edu>
SIGACT News needs YOU!
Announcing the inauguration of a new feature of SIGACT News:
The THEORETICAL COMPUTER SCIENCE EDUCATOR'S FORUM.
This free-form "forum" will be a place for those who teach theoretical
computer science to exchange ideas about courses, books, etc.
Although many types of contributions are possible, we would
like initially to solicit COURSE OUTLINES. In a fast-developing
field like theoretical computer science, there often do not exist
textbooks to cover advanced courses, so educators regularly create
new courses based on technical papers, etc. Even when texts
do exist, the courses based on them are often organized very
differently from the texts. I have seen much evidence of this
in visiting universities around the country, where I almost always
see interesting outlines and prospectuses taped on office doors
or tacked to bulletin boards. So this is a plea that you share
your educational ideas with the rest of us, by submitting your
outlines to SIGACT News. No fixed format is required, but if
there is an associated bibliography, please include that too.
If you have already taught the course, comments about its success,
(and whether you were really able to cover all the topics in
the outline) would also be welcome.
Other kinds of contributions to the forum: (1) general articles
on the theory curriculum as it is taught at your institution (or
should be taught), (2) comparative reviews of the available standard
texts, (3) brief technical papers descibing new and presumably better
ways of presenting standard material or of proving old results,
(4) ``Letters to the editor'' (controversy welcomed).
We hope to initiate the forum in the next issue of SIGACT News, the
deadline for which is tentatively set at February 1, so please start
sending us your course outlines as soon as possible. As with all
other submissions, they should go to the Newsletter Editor:
Victor Miller
IBM Thomas J. Watson Research Center
P.O. Box 218
Yorktown Heights, NY 10598
Electronic submissions are also possible: victor@ibm.com (arpanet,csnet)
or victor@yktvmx (bitnet).
For those of you who may be unfamiliar with SIGACT News, it is one
of the main benefits of membership in SIGACT (ACM Special
Interest Group in Automata and Computability Theory - the SIG for
theoretical computer science), and as such provides an audience
of over 2000 members (a circulation that exceeds that of SICOMP).
Here are some other ideas for the kinds of contributions that would be
of interest to SIGACT News. If you do not wish to volunteer yourself,
we would welcome suggestions as to whose arms we might productively twist.
(If you know of anyone who has already written something appropriate,
please urge them to submit it, or let us know about it.
1. Quarterly reports on the backlogs of Theoretical Computer Science
journals. Here we're looking for a single volunteer to take on the
job or regularly gathering data and preparing a half-page table,
something like what is done in the AMS Notices. We can probably
help dig up names of journal contacts for you, if needed.
2. More book reviews, both of research monographs and of standard
course texts.
3. Brief (2 or 3 page) descriptions of your institution, the people
there, and the research going on there.
4. Conference reports (with pictures if possible).
4. Annotated bibliographies and surveys in relevant areas. More
columns analogous to Joe O'Rourke's Computational Geometry
column would be welcome.
5. Brief technical papers of reasonably general interest. We are NOT
interested in long and highly technical papers, as our papers are
not refereed.
6. Humorous articles with a theoretical computer science bent.
7. Articles about the theoretical computer science community from a
historical or sociological point of view, like the ``Genealogy of TCS''
published 5 years ago. (An update is due in 1988 and if anyone
is willing to help, please contact me.)
David Johnson, SIGACT Chairman
Room 2D-150
AT&T Bell Laboratories
(dsj@research.att.com)
∂23-Dec-87 2041 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: Complexity of optimal addition chains
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Dec 87 20:41:09 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Wed 23 Dec 87 20:35:58-PST
Received: by lindy.stanford.edu; Wed, 23 Dec 87 20:37:59 PST
Received: by Forsythe.Stanford.EDU; Wed, 23 Dec 87 20:39:24 PST
Received: by BYUADMIN (Mailer X1.25) id 1694; Wed, 23 Dec 87 21:38:57 MST
Date: Wed, 23 Dec 87 22:35:03 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"C. Papadimitriou" <PAPA@score.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "C. Papadimitriou" <PAPA@score.stanford.edu>
Subject: Re: Complexity of optimal addition chains
To: Local Distribution <aflb.tn@sushi.stanford.edu>
Finding the best addition chain has been conjectured to be NP-complete.
As I recall, Ravi Sethi and co-authors have shown that finding the best
addition chain for several numbers (to be computed together) is NP-complete.
---CHP
[The reference is: Downey, Leong, and Sethi, "Computing sequences with
addtion chains," SIAM J. Computing, 10, 3 (August 1981) 638-646. ]
∂24-Dec-87 1130 ullman@navajo.stanford.edu paper received
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Dec 87 11:30:21 PST
Received: by navajo.stanford.edu; Thu, 24 Dec 87 11:23:08 PST
Date: Thu, 24 Dec 87 11:23:08 PST
From: Jeff Ullman <ullman@navajo.stanford.edu>
Subject: paper received
To: nail@navajo.stanford.edu
"Transitive closure algorithms revisited: the case of path compressions"
R Agrawal, S. Dar, and H. Jagadish, Bell Labs, Murray Hill.
These guys invented "closed semirings," but they haven't got the
"closed" part, so they can only handle acyclic paths.
They also noticed, as in AHU-1974, that Floyd's and WArshall's algorithms
are really the same idea, and perhaps in their next paper, they'll
notice that Kleene's algorithm is too.
And if they do that, perhaps next they'll rediscover data flow analysis,
as in Kildall's algorithm from 1971.
I hate to sound bitter, this being the holiday season and all, but
seeing work like this could almost make a fella believe that people
working in database systems need to know something about theory,
something about programming languages, something about ...
---jeff
∂25-Dec-87 0120 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #99
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 25 Dec 87 01:19:56 PST
Date: Thu 24 Dec 1987 07:13-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #99
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Friday, 25 Dec 1987 Volume 5 : Issue 99
Today's Topics:
Query - Debugging,
Implementation - termCompare/3,
Theory - Complexity
----------------------------------------------------------------------
Date: 23 Dec 87 01:34:44 GMT
From: munnari!mulga!ysy@uunet.uu.net (Song Yan)
Subject: Declarative Debugging in Non-standard Logic Programming
I am doing some research in declarative debugging in logic
programming, and going to extend the result into the non-standard
logic (temporal logic, modal logic and fuzzy logic) programming. Does
anybody show interest or has anyone done some work in this area? Any
ideas, comments, meta-interpreters are most welcome and appreciated.
Any programs in non-standard logic are also appreciated. If you have
done some work in debugging in standard logic programming, I would be
very interested in conducting correspondence with you.
-- Song Y. Yan
------------------------------
Date: Mon, 14 Dec 87 14:11:38 +1100
From: Jeff Schultz <munnari!mulga.oz.au!jws@uunet.UU.NET>
Subject: NU-Prolog termCompare/3.
This bug was fixed in patch 1.1-1 which was distributed by e-mail in
early November. If you have a version earlier than 1.2 and have not
received the patch, please send me a valid e-mail address.
Only a few tapes with this bug were distributed.
------------------------------
Date: Wed, 23 Dec 87 03:13:09 PST
From: quintus!ok@Sun.COM (Richard A. O'Keefe)
Subject: Complexity
Well, I've just about convinced myself that it can't be done.
It is easy to show that a pure functional language cannot generate
random permutations in O(N) time. The argument is the same as the
proof that sorting by comparison takes O(NlogN) time: there are N!
different permutations, so running the program must supply O(NlogN)
bits, but a single computational step in a pure functional language
can only supply a fixed number of bits. (Let's take a computational
step as being matching one constructor function or applying one
primitive function.) Don't forget that fixnum arithmetic yields a
fixed number of bits, and bignum arithmetic just hides the logarithmic
factor in the arithmetic.
We can give a precise meaning to a computational step in a Prolog
program too. Basically, the cost of a predicate head is proportional
to its size, and the cost of a goal is proportional to its size EACH
time it is executed. Because goals in the body of a clause may be
executed different numbers of times, the cost of a clause is data-
dependent. We charge unit cost for arithmetic. It is possible to
implement functor/3 and arg/3 so that they have constant cost
independent of the size of the term (modulo caveats about the
ultimate unreality of unbounded linear structures in ANY programming
language) though functor/3 is not usually so implemented.
General unification (V1 = V2 where neither is the first occurrence of
a variable) is the joker: the cost of this is data dependent, but it
is not less than unit cost.
There are two ways that you can code some bits: you can code them in
a number, or you can code them in the location of your data. In the
case of permutation generation, N! is too big to code in a fixnum for
all but a few N. (13! is the highest that fits in 32 bits.) So we
have to code a permutation as a distribution of items in a data
structure.
What gives the "unbounded term" languages the illusion of being
able to support O(N) random permutation generation is that there
is a number NMAX such not only can they generate lg(NMAX)
"arithmetic" bits in a single step, they can generate lg(NMAX)
"locational" bits in a single step. Provided N =< NMAX, they
can generate a permutation over [1..N] in O(N) time and space.
(And Prologs with unbounded terms are in this class.)
However, pure Prolog has one more operation than pure functional
languages: it can not only fill in a hole in unit time, it can
fill any (predetermined) number of holes in with the same value
in unit time. Is this enough to make a difference?
So we have a more precise version of the original question:
by exploiting logical variables, is it possible to generate
more than lg(T) "locational" bits in a single step?
I suspect that the answer is no. I'll put it in the form of a
Science Fiction idea, which I'll call for obscure reasons
"The Sansato Hypothesis".
If you have instantaneous matter transmitters
which only work one way
and which destroy themselves after a single use
and have to be placed by rockets (you can't transmit them)
then you're not much better off than if you only have rockets.
More precisely, a civilisation with such means of transport can
only expand twice as fast as one with rockets alone.
It turns out that such matter transmitters ARE good for internal
communication: what you have to do is set up pipelines of rockets
sending matter transmitters to interesting places, so that at any
one predetermined place you only have to wait a day for the next
matter transmitter to arrive, even if it took 1,000 years to get
there.
So there we have it:
there is reason to believe that Prolog can be as efficient as
conventional languages for fixed simple patterns of communication.
we have some idea of what a proof that Prolog cannot generate
permutations with the quasi-asymptotic efficiency of Fortran
might look like.
there is reason to believe that a parallel Prolog MIGHT have
more opportunities for speedup than a parallel functional
language (you have a chance to set up those pipelines).
Is it possible to set up a "systolic" network of FCP processes
which will deliver a stream of permutations with the same delay
that a network of Linda processes would require (whatever that is)?
There's an important point in all of this, even if you aren't
interested in permutations as such. The point is that, just as
designing efficient parallel algorithms is not a matter of taking
sequential algorithms and parallelising them (not always), so
designing efficient algorithms for Prolog is not a matter of taking
Pascal algorithms and turning them into "logic" (not always).
I've actually found the little that I know about parallel algorithms
(the *very* little) helpful in trying to design efficient Prolog
algorithms, and I suspect that I would find that approach still more
helpful in NU Prolog.
There's another interesting point: it isn't being "single-assignment"
which is the problem. Unbounded-term Prologs can (with the aid of !)
get O(N) expected time for this problem, without changing any bindings.
The key is being able to generate lg(K) bits of locational information
by calling arg/3 on a term of arity K. It looks as though there is a
weaker operation than array update which will solve this problem:
can we find a logical specification for it, and how will if perform
with other problems?
PS: it seems I missed a point in the Warren&Maier text. They knew
their findall/3 didn't work, didn't want it to, and said so in the
text. It was the similarity of the name to findall/3 which confused
me.
------------------------------
End of PROLOG Digest
********************
∂28-Dec-87 1519 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Preliminary Program STOC '88
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Dec 87 15:19:35 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Mon 28 Dec 87 15:16:56-PST
Received: by lindy.stanford.edu; Mon, 28 Dec 87 15:15:25 PST
Received: by Forsythe.Stanford.EDU; Mon, 28 Dec 87 15:16:32 PST
Received: by BYUADMIN (Mailer X1.25) id 1943; Mon, 28 Dec 87 16:13:39 MST
Date: Mon, 28 Dec 87 15:13:28 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Jeff Ullman <ullman@navajo.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Jeff Ullman <ullman@navajo.stanford.edu>
Subject: Preliminary Program STOC '88
To: Local Distribution <aflb.tn@sushi.stanford.edu>
Monday, May 2, 1988.
Session 1,9---10:20 am,Andrew Odlyzko.
Completeness Theorems for Non-Cryptographic Fault-Tolerant Distributed
Computation.
Michael Ben-Or, Hebrew University,
Shafi Goldwasser, MIT, and
Avi Wigderson, Hebrew University.
Multiparty Unconditionally Secure Protocols.
David Chaum, Centre for Mathematics and Computer Science,
Claude Crepeau, MIT, and
Ivaa Damgard, Aarhus Universitet.
On the Power of Oblivious Transfer.
Joe Kilian, MIT.
How to Sign Given Any Trapdoor Function.
Mihir Bellare and
Silvio Micali, MIT.
Coffee 10:20---10:50 am.
Session 2,10:50 am---12:30 pm,Nancy Lynch.
A Tradeoff Between Space and Efficiency for Routing Tables.
David Peleg, Stanford University, and
Eli Upfal, IBM Almaden.
Reasoning About Knowledge and Time in Asynchronous Systems.
Joseph Halpern and
Moshe Vardi, IBM Almaden.
Investigations of Fault-Tolerant Networks of Computers.
Piotr Berman, Penn State University, and
Janos Simon, University of Chicago.
Toward a Non-Atomic Era: 1-Exclusion as a Test Case.
Danny Dolev, IBM Almaden and Hebrew University,
Eli Gafni, UCLA, and
Nir Shavit, Hebrew University.
A Time-Randomness Tradeoff for Oblivious Routing.
David Peleg, Stanford University, and
Eli Upfal, IBM Almaden.
Lunch
Session 3,2---5:30 pm,TBA.
Non-Interactive Zero-Knowledge and its Applications.
Manuel Blum, University of California, Berkeley,
Paul Feldman and
Silvio Micali, MIT.
Multi-Prover Interactive Proofs: How to Remove Intractability.
Michael Ben-Or, Hebrew University,
Shafi Goldwasser, MIT,
Joe Killian, MIT, and
Avi Widerson, Hebrew University.
A Knowledge-Based Analysis of Zero Knowledge.
Joseph Halpern, IBM Almaden,
Yoram Moses, Weizmann Institute, and
Mark Tuttle, MIT.
From Scratch to Byzantine Agreement in Constant Expected Time.
Paul Feldman and
Silvio Micali, MIT.
Coffee 3:20---3:50 pm.
Session 4,3:50---5:30 pm,TBA.
On Different Modes of Communication.
Bernd Halstenberg and
Rudiger Reischuk, Technische Hochschule Darmstadt.
Virtual Memory Algorithms.
Alok Aggarwal and
Ashok Chandra, IBM Yorktown Heights.
On the Communication Complexity of Graph Properties.
Andras Hajnal, University of Illinois at Chicago and
Hungarian Academy of Sciences,
Wolfgang Maass, University of Illinois at Chicago, and
Gyorgy Turan, University of Illinois at Chicago and
Hungarian Academy of Sciences.
Optimal Simulations by Butterfly Networks.
Sandeep Bhatt, Yale University,
Fan Chung, BellCore,
Jia-Wei Hong, Beijing Computer Institute and Courant Institute of NYU,
Tom Leighton, MIT, and
Arnold Rosenberg, University of Massachusetts at Amherst.
Energy Consumption in VLSI Circuits.
Alok Aggarwal,
Ashok Chandra, and
Prabhakar Raghavan, IBM Yorktown Heights.
\day
Tuesday, May 3, 1988.
Session 5,9---10:20 am,TBA.
Random Instances of a Graph Coloring Problem are Hard.
Ramarathnam Venkatesan and
Leonid Levin, Boston University.
Expressing Combinatorial Optimization Problems.
Mihalis Yannakakis, AT\&T Bell Labs, Murray Hill.
Optimization, Approximation, and Complexity Classes.
Christos Papadimitriou, University of California, San Diego, and
Mihalis Yannakakis, AT\&T Bell Labs, Murray Hill.
Conductance and the Rapid Mixing Property for Markov Chains:
the Approximation of the Permanent Resolved.
Mark Jerrum and
Alistair Sinclair, University of Edinburgh.
Coffee 10:20---10:50 am.
Session 6,10:50 am---12:30 pm,TBA.
Relativized Polynomial Time Hierarchies Having Exactly K Levels.
Ker-I Ko, SUNY at Stony Brook.
Computing Algebraic Formulas with a Constant Number of Registers.
Richard Cleve, University of Toronto.
On the Power of White Pebbles.
Balasubramanian Kalyanasundaram and
George Schnitger, Penn State University.
Learning in the Presence of Malicious Errors.
M. Kearns and
M. Li, Harvard University.
Nondeterministic Linear Tasks May Require Substantially Nonlinear
Deterministic Time in the Case of Sublinear Work Space.
Yuri Gurevich and
Saharon Shelah, University of Michigan.
Lunch
Session 7,2---3:20 pm,TBA.
Efficient String Matching.
S. Rao Kosaraju, Johns Hopkins University.
A Deterministic Algorithm for Sparse Multivariate Polynomial Interpolation.
Michael Ben-Or, Hebrew University, and
Prasoon Tiwari, IBM Yorktown Heights.
Randomized Algorithms and Pseudorandom Numbers.
Howard Karloff, University of Chicago, and
Prabhakar Raghavan, IBM Yorktown Heights.
Competitive Algorithms for On-line Problems.
Mark Manasse, DEC SRC,
Lyle McGeoch, Amherst College, and
Daniel Sleator, Carnegie Mellon University.
Coffee 3:20---3:50 pm.
Session 8,3:50---5:30 pm,Herbert Edelsbrunner.
Implicit Representation of Graphs.
Sampath Kannan,
Moni Naor, and
Steven Rudich, University of California, Berkeley.
Storing and Searching a Multikey Table.
Amos Fiat and Moni Naor, University of California, Berkeley,
Alexandro Sch\"affer, Stanford University,
Jeanette Schmidt and Alan Siegel, Courant Institute of NYU.
More Analysis of Double Hashing.
George Lueker and
Mariko Molodowitch, University of California, Irvine.
Linearity and Unprovability of Set Union Problem.
Martin Loebl and
Jaroslav Ne\u set\u ril, Charles University and Universit\"at Bonn.
More Perfect Hashing and Storing a Multikey Sparse Table.
Amos Fiat and Moni Naor, University of California, Berkeley,
Jeanette Schmidt and Alan Siegel, Courant Institute of NYU.
\day
Wednesday, May 4, 1988.
Session 9,9---10:20 am,Greg Frederickson.
A Faster Strongly Polynomial Minimum Cost Flow Algorithm.
James Orlin, MIT.
Finding Minimum-Cost Circulations by Canceling Negative Cycles.
Andrew Goldberg, Stanford University.
Detecting Cycles in Dynamic Graphs in Polynomial Time.
S. Rao Kosaraju and
Gregory F. Sullivan, Johns Hopkins University.
An Effcient Matroid Partitioning Algorithm and Applications.
Harold Gabow and
Herbert Westermann, University of Colorado at Boulder.
Coffee 10:20---10:50 am.
Session 10,10:50 am---12:30 pm,John Reif.
Geometry helps in matching.
Pravin M. Vaidya, AT\&T Bell Labs, Murray Hill.
Small Sets Supporting Fary Embeddings of Planar Graphs.
Hubert de Fraysseix, CNRS,
Janos Pach, Hungarian Academy of Sciences, and
Richard Pollack, Courant Institute of NYU.
Optimal Algorithms for Approximate Clustering.
Tomas Feder, Stanford University, and
Daniel Greene, Xerox PARC.
Planning Constrained Motion.
Steven Fortune and
Gordon Wilfong, AT\&T Bell Labs, Murray Hill.
Some Algebraic and Geometric Computations in PSPACE.
John Canny, University of California, Berkeley.
Lunch
Session 11,2---3:20 pm,Jeffrey Ullman.
Lower Bounds on the Complexity of Graph Properties.
Valerie King, University of California, Berkeley.
Decidable Optimization Problems for Database Logic Programs.
Stavros Cosmadakis, IBM Yorktown Heights,
Haim Gaifman, Hebrew University,
Paris Kanellakis, Brown University, and
Moshe Vardi, IBM Almaden.
Polynomial Universal Traversing Sequences for Cycles Are Constructible.
Sorin Istrail, Wesleyan University.
Two Infinite Sets of Primes with Fast Primality Tests.
Janos Pintz, Hungarian Academy of Sciences,
William Steiger, Rutgers University, and
Endre Szemer\'edi, Rutgers University and Hungarian Academy of Sciences.
Coffee 3:20---3:50 pm.
Session 12,3:50---5:30 pm,Richard Cole.
Towards an Architecture-Independent Analysis of Parallel Algorithms.
Christos Papadimitriou, University of California, San Diego, and
Mihalis Yannakakis, AT\&T Bell Labs, Murray Hill.
A Randomized Parallel Branch-and-Bound Procedure.
Richard Karp and
Yanjun Zhang, University of California, Berkeley.
Almost-Optimum Speed-ups of Algorithms for Matching and Related Problems.
Harold Gabow, University of Colorado at Boulder, and
Robert Tarjan, Princeton University and AT\&T Bell Labs, Murray Hill.
Using Smoothness to Achieve Parallelism.
Leonard M. Adleman and
Kireeti Kompella, University of Southern California.
Monotone Circuits for Connectivity Require Super-logarithmic Depth.
Mauricio Karchmer and
Avi Wigderson, Hebrew University.
∂30-Dec-87 1443 RICHARDSON@Score.Stanford.EDU General Faculty Meeting
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Dec 87 14:43:34 PST
Date: Wed 30 Dec 87 14:27:50-PST
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: General Faculty Meeting
To: faculty@Score.Stanford.EDU
Message-ID: <12362694261.34.RICHARDSON@Score.Stanford.EDU>
General Faculty Meeting
January 5, 1988
2:30 p.m.
MJH 146
Agenda
======
1. Approval of degree candidates, Sharon Hemenway
2. Staff Reports
a. Computer Forum
-Carolyn Tajnai
b. Computer Facilities
-Jim Ball
c. Financial
-Betty Scott
d. Other
3. Faculty Actions:
a. Courtesy Appointment for Prof. David Rumelhart, Psychology
-Nils Nilsson
b. Courtesy Appointment for proposed Assoc. Prof. Bernard Mont-Reynaud,Music
-Nils Nilsson
c. Consulting Professorship for Keith Lantz
-John Hennessy
d. Consulting Professorship for Moshe Vardi
-Jeff Ullman
e. Visiting Professorship for Neil Jones (Winter Quarter)
-John McCarthy
f. Proposed policy regarding reversion of unrestricted funds and
equipment when faculty/staff leave Stanford
-Nils Nilsson
g. Proposed policy change regarding departmental share of assignment of
rights income (see Nilsson e-mail)
-Nils Nilsson
-------
∂30-Dec-87 1448 RICHARDSON@Score.Stanford.EDU Tenured Faculty Meeting
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Dec 87 14:48:41 PST
Date: Wed 30 Dec 87 14:31:06-PST
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: Tenured Faculty Meeting
To: tenured@Score.Stanford.EDU
Message-ID: <12362694856.34.RICHARDSON@Score.Stanford.EDU>
There will be a tenured faculty meeting on Tuesday, January 5, 1988
immediately following the general faculty meeting to consider the possible
promotion of Ernst Mayr from Assistant to Associate Professor. Today and
tomorrow until 12:00 noon, the file on Mayr will be in my office for your
perusal. After that, the file will be in Betty Scott's office. Please come
by to look over the file in preparation for the meeting.
-Anne
-------
∂30-Dec-87 1508 TAJNAI@Score.Stanford.EDU Need Information re Kelar Corporation
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Dec 87 15:08:00 PST
Date: Wed 30 Dec 87 15:05:33-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Need Information re Kelar Corporation
To: faculty@Score.Stanford.EDU
Message-ID: <12362701127.23.TAJNAI@Score.Stanford.EDU>
Can any of you offer information on Kelar Corporation?
Date: Mon, 28 Dec 87 16:36:20 PST
From: Pamela Cook <CT.PAC@forsythe.stanford.edu>
To: tajnai@score.stanford.edu
Carolyn,
Thanks for your response on Kelar Corporation. I would be delighted
if you could query people on whether they know anything about a gift
of software to the School or CS Department from this company since I
do not have any information on them. The donor, whose name is
Kambiz Taleghani, is a Civil Engineering grad. He said that his
company, Kelar Corp, based in Los Angeles, contributes software to
the School of Engineering. If the company is making such gifts we
ought to be making some record of it in our system and right now we
do not have any record of that company. thanks for anything you
learn.
Pam Cook
-------
∂31-Dec-87 0122 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V5 #100
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 31 Dec 87 01:22:39 PST
Date: Wed 30 Dec 1987 06:02-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V5 #100
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Thursday, 31 Dec 1987 Volume 5 : Issue 100
Today's Topics:
Announcement - New List,
Implementation - String Concatenation
----------------------------------------------------------------------
Date: Wed, 16 Dec 87 14:45:25 CST
From: reddy@b.cs.uiuc.edu (Uday S. Reddy)
Subject: Mailing list on narrowing
A new mailing list dedicated to the discussion of narrowing in
functional and equational languages is being created. Narrowing is an
operational mechanism using which expressions with free variables can
be "executed" producing solutions for the free variables. This is one
of the approaches to combining functional programming and logic
programming paradigms into a unified framework.
The mailing list will be based at University of Illinois, at the
address narrow@a.cs.uiuc.edu. Please send requests for addition to
the mailing list to narrow-request@a.cs.uiuc.edu or
reddy@a.cs.uiuc.edu.
-- Uday Reddy
------------------------------
Date: Tue, 29 Dec 87 00:06:55 PST
From: quintus!ok@Sun.COM (Richard A. O'Keefe)
Subject: On String Concatenation
Although several Prolog dialects provide operations on strings, as
many more do not, and among those that do, the names and capabilities of
the operations vary considerably. Most of them are just warmed-over
BASIC, which means that as part of a "logic" programming language they
are very badly designed indeed. Come to that, they aren't all that
wonderful in BASIC, either. And if people at ----- or --- or --- or ---
or ------ ------- ------------- think I'm talking about their product, I
*am*. Very badly designed indeed. Most of the others are warmed-over
Lisp, which means that although they are not that badly designed, they
may fairly be described as excessively restrictive.
I have just been looking at a medium size program (6,400 lines of
Prolog-with-a-blunt-knife) which uses string concatenation lavishly.
Just in case you are alarmed, this is NOT the Quintus Prolog compiler,
nor any other Quintus product. In the Quintus Prolog version of this
program, the operation is coded thus:
concat_atom(Constants, Atom) :-
concat_chars(Constants, Chars),
atom_chars(Atom, Chars). % you may need name/2
concat_chars([], []).
concat_chars([Constant|Constants], Chars) :-
name(Constant, Name),
append(Name, Chars1, Chars),
concat_chars(Constants, Chars1).
This is fine, as far as it goes. Prolog atoms are an almost
perfect analogue of SNOBOL IV strings. But there are three snags:
(a) in most Prolog systems known to me, the atom length bound is
smaller than the string length bound. A good design rule is
that the Prolog atom length bound should be no less than the
host operating system's file-name length bound, which is about
1024 in a good UNIX. Few Prolog systems meet this not-very-
stringent condition.
(b) in many Prolog systems there is a smallish limit on the number
of atoms you can have. For example, in --- Prolog, you can
only have 907. When you recall that NU7 Prolog, running on a
PDP-11 with 64kbytes of address space, would let you have 1023
atoms, a limit of 907 on an IBM PC or a Macintosh is absurd.
Come to that, any limit other than "storage exhausted" is absurd.
(c) Restriction (b) might be tolerable, but most Prolog systems do
not garbage collect atoms. (There is no reason why they can't,
they just don't.)
So if you rely too heavily on concat_atom/2, you run the risk of
(a) not being able to represent the result, (b) running out of atoms
-- even though there might be lots of storage left --, or (c) tying
up storage forever with atoms that were useful once.
This sounds like a powerful argument for having a string data-
type in the language. But is it?
(a) There is no reason why atoms should have to be short. If space
is tight, you might want to represent "normal" atoms by a
pointer to a length byte followed by that many characters, but
there is no reason why you couldn't reserve length 255 to mean
"long name" and use some other representation for long atoms.
(b) There is no good reason for the atom count limit being small.
I put together a symbol table design for the IBM PC where the
limit was 2↑16 minus a few; this didn't even store atom lengths
explicitly, and was very compact. If you can do it for the IBM
PC, you can do it for decent machines.
(c) There is no reason why the atom table couldn't be garbage
collected. SNOBOL did it, after all.
But still, it must be more efficient to allocate strings in the same
area as compound terms and have them vanish on backtracking, and never
have to look them up in the symbol table? This is almost certainly
true, but the odd thing is that if efficiency is your concern you are
better off using lists of character codes than strings. This is a very
surprising result, but it is true in the Lisp systems I have tried too.
[In case this isn't clear, I mean that I have MEASURED the cost of
strings -vs- lists of character codes, and found that in well-designed
Prolog and Lisp systems using lists is FASTER.]
Even if efficiency is on the side of lists of character codes, they
do take up more space than strings. So there is still some sort of an
argument for strings here, especially on PCs and Mac. True, but there
is a better argument for not doing concatenation at all.
I thought it would be interesting to see how the program mentioned
above used concatenation. Eight different uses could be found:
(1) Making a file name.
The typical example was
concat_atom([Base,'.s'], AssemFileName),
open(AssemFileName, write, AssemStream)
(2) Making a prompt.
The typical example was
concat_atom(['(',State,') ?- '], NewPrompt),
prompt(OldPrompt, NewPrompt),
<stuff>
prompt(_, OldPrompt)
(3) Making a comment to write in a generated file.
The typical example was
concat_atom(['# Date : ',Day,-,Month,-,Year], DateLine),
...
write_to_assem_file([FileLine,DateLine,VersionInfo])
(4) As a preliminary to making a list of character codes,
also to be written in a generated file.
The typical example was
concat_atom(['source function: ',Function,/,Arity], Comment),
name(Comment, CommentChars),
...
write_to_assem_file([...,c(CommentChars),...])
(5) Changing the name of a compound term.
This particular program has two families of constructor functions
(among others): where one has <foo> the other has c<foo>.
The typical example was
PlainTerm =.. [PlainFunction|Args],
concat_atom([c,PlainFunction], DecoratedFunction),
DecoratedTerm =.. [DecoratedFunction|Args]
(6) Constructing an error message.
The typical example was
target_machine(Machine),
concat_atom(['A ',Machine,' cannot handle ',
Operation,' on ',Size,' data'], ErrMsg),
report_error(ErrMsg, ...)
(7) Turning a term into an atom.
The typical example was
flatten(X+Y, Flat) :-
flatten(X, X1),
flatten(Y, Y1),
concat_atom([X1,+,Y1], Flat).
(8) Generating labels.
The typical example was
label_bounds(vms, '', '$').
label_bounds(unix, 'L', '').
make_label(Number, Label) :-
target_os(OS),
label_bounds(OS, Prefix, Suffix),
concat_atom([Prefix,Number,Suffix], Label).
Comments.
(1) This shows up a real deficiency in most Prolog systems, but the
solution adopted was no better. Common Lisp has addressed this
problem. The problem is the problem of handling file names in
a reasonably portable way. We have something for internal use
here that looks quite good, but then we decided to do an IBM
mainframe port, and it didn't look quite so portable any more.
What we'd really like to do in this case is
file_extension(assembler, Extension),
open('b.e'(Base,Extension), write, AssemStream)
or something like that.
The relevance of this to string operations is that we don't
really want a string (or, for that matter, an atom) at all.
The syntax of file names is something we want to keep OUT of
our source code. What we want here is operations on file
names such as Common Lisp provides, not operations on strings.
In fact string operations are unbelievably clumsy for such
elementary things as "parent directory".
(2) The prompt/2 operation being specified to take atoms, concat_atom/2
is needed here. On the other hand, prompt/2 doesn't do quite what
the programmer of this program thought (it sets the prompt used by
*programmed* input, not the prompt used by the top level) so in
fact the operation accomplished nothing at all. So this can't be
all that vital. In any case, it only happens once, so making an
atom is no big deal.
(3) String concatenation should not be used here (A).
(4) In this case, it would have been better to call concat_chars/2
directly, rather than pack the result into an atom and straight
away unpack it again. Anyway, string concatenation should not
be used here (A).
(5) The right way to do this is to make a table
decorate(foo(X,Y), cfoo(X,Y)).
decorate(baz(X), cbaz(X)).
decorate(ugh(X,Y,Z), cugh(X,Y,Z)).
...
decorate(PlainTerm, DecoratedTerm)
...
This is considerably faster and purer.
(6) String concatenation should not be used here (B).
(7) String concatenation should not be used here (A).
(8) String concatenation should not be used here (A).
(A) All of these particular uses are constructing something which
is going to be written to a file. Now, we DO care that the
right sequence of characters should be written to the file,
but we DON'T need to represent that sequence of characters
EXPLICITLY in the program!
For example, we can handle example (8) thus:
make_label(Number, label(Number)).
...
write_operand(label(Number)) :-
target_os(OS),
label_format(OS, Format),
format(Format, [Number]).
Example (7) and lots of others like it in the program can be
handled by more clauses of the same sort:
write_operand(A+B) :-
write_operand(A),
write(+),
write_operand(B).
What is happening here is that instead of constructing a string
we are constructing a compound term, and finally we are saying
how to print these compound terms.
There are so many advantages to doing it this way! For example,
we can easily produce several different printing routines (not
just different ones for different operating systems; we could
have a debugging version which prints abbreviated forms to the
terminal so that we can see what is happening). Best of all,
we keep the data structures as *Prolog* data structures for as
long as possible, meaning that we can unpack them using
unification rather than slow string operations, and we can leave
parts of them uninstantiated (for all time, if we so choose).
The long and short of it is that this approach is much more
efficient, and much more flexible, than consing character strings
all over the place.
(B) Once again, the program as such has no use for the character
string. The appropriate thing is to imitate Common Lisp (well,
when we did it in DEC-10 Prolog years ago, we thought we were
imitating C, but it comes to the same thing). Instead of
consing up a string, you pass your error reporting command a
format and a list of arguments. Thus we might do
target_machine(Machine),
report_error('A ~w cannot handle ~w on ~w data',
[Machine,Operation,Size], ...)
report_error(Format, Arguments, ...) :-
current_input(Stream),
current_stream(FileName, read, Stream),
line_count(Stream, Line),
format(user_error, '~N! Error near line ~w of ~w~n! ',
[Line, FileName]),
format(user_error, Format, Arguments),
format(user_error, '~n', []),
interact_with_user(...).
format/2 and format/3 are specific to Quintus Prolog, just as
writef/2 and fwritef/3 were specific to DEC-10 Prolog. That
doesn't matter. It is trivially easy to knock together something
of the sort which is powerful enough to handle your error messages.
The same technique of passing around a "format" and a list of
arguments for it may be applicable in other cases as well.
The point is:
unless the program itself has a use for the string,
don't make it. Leave the thing as a compound term or something
right up until you write it out.
It is sobering to reflect that the reason why C is such a good language
for writing text-processing applications is that it HASN'T got a string
data type.
Some other operations.
(i) Pattern matching.
Grammar rules are far and away the best way of doing this in Prolog.
SNOBOL and ICON fans will recognise most of their favourite
pattern matching operations as basic Prolog control structures
(cut = FENCE) and as I pointed out earlier, grammar rules in a
good Prolog are likely to be faster than string operations.
(ii) Accessing data fields in external data bases.
The argument here is that the external data base may contain
millions of character fields which we do not loaded into Prolog's
symbol table. This is a very strong argument indeed in favour of
what have been called "uninterned atoms" (more or less what all
the atoms in the LOGIX system are). But
(ii.1) If the external data base is a relational one, and if the
data base designer had even the faintest understanding of
what it means to design a relational data base, you will not
want to do string operations on these character fields.
(Domains in a relational data base are supposed to be ATOMIC
as far as the application is concerned.) Dates might be an
exception, but they should be stored as a DATE data type or
as coded numbers.
(ii.2) If you are going to do any joins in Prolog, you definitely
DO want the attributes in that domain to be held uniquely (at
least for the duration of a query) in Prolog, so why not put
them in the hash table?
(iii.3) Attributes which are only involved in selection, and are not
included directly in the answer, should be kept on the other
side of the interface.
So the set of attributes where uninterned atoms are wanted is the
set of attributes which are going to be printed but not used in
joins on the Prolog side of the interface (and in particular, are
not going to be stored in the internal data base).
For this application, it looks as though an atom symbol table
which lent itself to fast garbage collection would be little if
at all worse than the use of uninterned atoms.
I have used a lot of programming languages having a string data
type. I am STILL looking for an application where it would be a good
idea to use them in a Prolog which had them. If we can't get a
discussion going about Prolog textbooks, can we get a discussion going
about this?
The topic for debate is:
assuming a Prolog system which imposes no arbitrary
restrictions on atoms, so that the only difference between
atoms and strings is that atoms are stored uniquely and
recovered by garbage collection (so allocation is slow,
but equality testing is rapid) whereas strings are not
stored uniquely and are recovered by both backtracking
and garbage collection (so allocation is fast but
equality testing is slow)
what examples can be found, OTHER than communication with
another language (such as Lisp) which supports strings,
where it is a good idea to USE strings?
Practical experience concerning the relative utility of
strings and uninterned atoms from people who are interfacing
Prolog with a large external data base would be useful.
------------------------------
End of PROLOG Digest
********************
∂31-Dec-87 1258 AAAI-OFFICE@SUMEX-AIM.Stanford.EDU New Committees and Chairs
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 31 Dec 87 12:57:59 PST
Date: Thu, 31 Dec 87 12:54:21 PST
From: AAAI <AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>
Subject: New Committees and Chairs
To: officers: ;
cc: aaAI-OFFICE@SUMEX-AIM.Stanford.EDU
Telephone: (415) 328-3123
Postal-Address: 445 Burgess Drive, Menlo Park, CA 94025
Message-ID: <12362939386.28.AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>
Happy New Year!
During the Fall, the Executive Committee reviewed the current composition
of the existing committees and suggested that some committee chair positions
needed to change. The Execom devised a method of chair rotation which ensures
continuity and progression.
It was decided that the current chair would remain on the committee in a
steering position for 2 years. The new chair would be the standing chair
for the same period of time and would nominate his/her successor.
This procedure would apply for the following committees: Finance, Publications,
Fellowship, Scholarship, Conference and Workshops. The other committees,
Nominating, Program, and Symposium, usually rotate chairs annually.
But, before we begin to review the list of chair nominations, we need to
approve the following new committees. During the past Council meetings,
we have organize and/or nominated new committees, but we have not formally
voted on their existence. According to the bylaws, the Council, "by a
resolution adopted by an affirmative majority vote of the number of
councilors in office provided a quorum is present, may designate
one or more committees."
The charters of the following new Committees are:
FELLOWSHIP COMMITTEE: Committee will solicit, review and monitor nominations
for post-doctoral fellowships which will be for a two year span.
SCHOLARSHIP COMMITTEE: Committee will review and select students to
receive grants to attend the National Conference on Artificial Intelligence.
SYMPOSIUM COMMITTEE: Committee is responsible for the selection of topics
and their chairs and overseeing the Series's program development.
PLEASE VOTE ON THE FOLLOWING COMMITTEES:
YES NO
FELLOWSHIP COMMITTEE
SCHOLARSHIP COMMITTEE
SYMPOSIUM COMMITTEE
*************************************************************************
If all the new committees have been approved, the following people
have been nominated (and contacted) for these committees. They are:
YES NO
SCHOLARSHIP ---
Raj Reddy
SYMPOSIUM ---
Hector Levesque
Nominees to the Fellowship Committee is still pending.
For the rest of the standing committees, here are the nominees:
YES NO
CONFERENCE ---
Howard Shrobe
FINANCE ---
Bruce Buchanan
WORKSHOP ---
Peter Hart
Chair nominations to the Publication Committee are still pending.
The chairs of the Nominating and Program Committee have not
been nominated.
Could you please vote on these nominations and return your response
by January 15?
Thank you for your attention to this important matter!
Claudia
PS We're planning to hold a spring Council meeting on Friday, March 25
(the day after the Symposium Series) in Palo Alto. I need to know your
thoughts on the issues for discussion and the proposed date of the
meeting.
-------
∂01-Jan-88 0156 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V6 #1
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Jan 88 01:56:39 PST
Date: Thu 31 Dec 1987 06:29-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V6 #1
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Friday, 1 Jan 1988 Volume 6 : Issue 1
Today's Topics:
Administration - Archives,
Puzzles - Tick & Baskett
----------------------------------------------------------------------
Date: Thu 31 Dec 87 06:27:29-PST
From: Chuck Restivo <Restivo@Sushi.Stanford.EDU>
Subject: Archives
We are entering the sixth year the Digest has been produced. Archives
for all past issues are available for FT from {SU-SUSHI.STANFORD.EDU}
under the <PROLOG.DIGEST> directory. Each year's issues are organized
in an individual volume. The volume's can be read with MM but will
still be useful if your site does not support that utility. {SUSHI:}
observes typical anonymous login conventions.
The Stanford Crew are a swell bunch of guys. I would like to thank
the Computer Science Department at Stanford University for continuing
to provide the resources that we have all benefited from. Special
thanks are in order to Lester Earnest and Professor McCarthy.
-- ed
SUSHI:<PROLOG.DIGEST>
.VOLUME1.1;P770000 188 478729(7) 23-Jan-87 19:41:48 RESTIVO
.VOLUME2.1;P770000 189 482235(7) 24-Jan-87 10:00:54 RESTIVO
.VOLUME3.1;P770000 221 563713(7) 24-Jan-87 10:39:33 RESTIVO
.VOLUME4P1.1;P770000 121 308281(7) 24-Jan-87 10:43:32 RESTIVO
.VOLUME4P2.1;P770000 281 719256(7) 23-Dec-86 00:04:48 RESTIVO
.VOLUME5P1.1;P775202 177 451342(7) 29-Oct-87 03:19:57 RESTIVO
.VOLUME5P2.1;P775202 278 711647(7) 31-Dec-87 05:22:34 RESTIVO
Total of 1638 pages in 9 files
------------------------------
Date: Thu, 31 Dec 87 11:35:58 PST
From: <udi%WISDOM.BITNET@CNUCE-VM.ARPA>
Subject: Evan's puzzle
In a recent note Evan Tick suggested that the fate of concurrent logic
programming languages is endangered by a certain benchmark problem,
Forest Baskett's puzzle. He said that he tried implementing it in
FGHC, but failed: either the program ran for four hours without
solving the problem, or it ran out of space.
Enclosed are two solutions to the problem, written in FCP. The first
is a manual partial-evaluation of a variant of the Or-Parallel Prolog
interpreter written in FCP (see reference below), with respect to
Evan's original Prolog program that solves the puzzle. The
interpreter used differs from the original interpreter in the that it
employs parallel depth-first, rather then parallel breadth-first,
search strategy, and stops after the first solution is found. This is
according to the problem specification. The number of processors
participating in the search is a program parameter.
The program solves the puzzle (with one processor) in about 4.5 CPU
minutes on a Sun-3/50, and in 85 CPU seconds on a CCI Power/6.
For comparison, Evan's Prolog program runs interpreted under
Quintus Prolog Version 1.0 on the Sun-3/50 for 55 seconds,
and compiled 12 seconds, and under C-Prolog on the CCI
for 11 CPU seconds. The FCP program was not yet ported to the parallel
implementation of FCP on the iPSC Hypercube, but experience with
previous programs suggest that with 16 processors a speedup of about
10 is attainable (after scaling processor speeds, of course).
The second solution is a brute-force depth-first Or-parallel Prolog
interpreter, which, instead of recomputing alternative branches,
simply freezes the state on each choice point, and melts it for the
alternative choices. It solves the puzzle in 3.8 CPU minutes on a
Sun-3/50 (60 seconds on the CCI). It was not ported to the iPSC Hypercube
either, but I expect smaller speedup, since instead of communicating prefixes,
which are lists of small integers, it communicates frozen states, which are
a much bigger data-structure.
I will report the performance results for the hypercube when we port
these programs, probably after Steve Taylor returns from the U.S.
in February.
Evan was mainly interested in an FGHC solution. Unfortunately, the
FCP solution can not be easily ported to FGHC, since the program
uses full test-unification in an essential way, inheriting
it from Evan's original Prolog program. This is a manifestation of
the general statement, made in the "Or-Parallel Prolog in FCP" paper,
concerning the inadequacy of GHC and PARLOG to interpret Prolog,
because of their weaker notion of unification.
The paper appeared in "Logic Programming: Proc. of the Fourth
International Conference", (JL Lassez, ed.), and (slightly revised) in
"Concurrent Prolog: Collected Papers" (E. Shapiro, ed.), both by MIT
Press.
-- Ehud Shapiro
udi@wisdom.{bitnet,csnet}
p.s. There is a discrepancy between Evan's verbal description of the problem
("All 2005 solutions must be calculated and counted, but not
printed.") and the Prolog program he wrote, which finds the first solution,
and counts the (2005) steps leading to it. Perhaps he tried solving
in FGHC the `all-solutions' problem, which has of course a much larger
search space. The FCP programs follow Evan's Prolog code rather then
his verbal description.
A note on the programs:
It will probably be hard to understand the programs without first reading
Evan's Prolog program and the Or-Parallel Prolog in FCP.
The programs are a bit more cumbersome then needed, since they also
solve a simpler puzzle that was used for debugging.
The programs are written in Typed FCP. They can be run on older versions
of Logix that do not support Typed FCP by commenting out the type
definitions and declarations.
*** Evan's original Prolog program:
%------------------------------------------------------------------------------
% Benchmark Program - Puzzle (Quintus Prolog Version)
% Lisp vs. Prolog Study
%
% Copyright by Evan Tick
% Date: October 30 1985
%
% To test or collect statistics: run test/0.
% Should print "2005 trials".
%------------------------------------------------------------------------------
:- dynamic count/1.
test :-
make_board(Board),
initialize(Board,Pieces),
play(Board,Pieces).
initialize([Spot|_],[[b,c,d,e,f,g,h,i,j,k,l,m],[n,o,p],[q],[r]]) :-
(retract(count(_));true),assert(count(1)),
p1(a,Spot). % first move fixed
play([],_) :- % game over
count(N),write(N),write(' trials'),nl.
play([s(V,_,_,_)|Rest],Pieces) :- % spot already filled
nonvar(V),!,
play(Rest,Pieces).
play([Spot|Rest],Pieces) :-
fill(Spot,Pieces,NewPieces), % spot empty - try to fill
incr,
play(Rest,NewPieces).
incr :-
retract(count(Count)),NCount is Count+1,
% write(Count),nl,
assert(count(NCount)),!.
fill(Spot,[[Mark|P1]|T],[P1|T]) :- p1(Mark,Spot).
fill(Spot,[P1,[Mark|P2]|T],[P1,P2|T]) :- p2(Mark,Spot).
fill(Spot,[P1,P2,[Mark|P3]|T],[P1,P2,P3|T]) :- p3(Mark,Spot).
fill(Spot,[P1,P2,P3,[Mark|P4]|T],[P1,P2,P3,P4|T]) :- p4(Mark,Spot).
% piece templates:
% p1 = 4x2x1: 6 orientations
% 4-2-1
p1(M,s(M,s(M,s(M,s(M,_,C13,_),C12,_),C11,_),s(M,C11,_,_),_)) :-
C13 = s(M, _,_,_),
C12 = s(M,C13,_,_),
C11 = s(M,C12,_,_).
% 2-1-4
p1(M,s(M,s(M,_,_,C11),_,s(M,C11,_,s(M,C12,_,s(M,C13,_,_))))) :-
C13 = s(M,_,_, _),
C12 = s(M,_,_,C13),
C11 = s(M,_,_,C12).
% 1-4-2
p1(M,s(M,_,s(M,_,s(M,_,s(M,_,_,C13),C12),C11),s(M,_,C11,_))) :-
C13 = s(M,_, _,_),
C12 = s(M,_,C13,_),
C11 = s(M,_,C12,_).
% 2-4-1
p1(M,s(M,s(M,_,C11,_),s(M,C11,s(M,C12,s(M,C13,_,_),_),_),_)) :-
C13 = s(M,_, _,_),
C12 = s(M,_,C13,_),
C11 = s(M,_,C12,_).
% 4-1-2
p1(M,s(M,s(M,s(M,s(M,_,_,C13),_,C12),_,C11),_,s(M,C11,_,_))) :-
C13 = s(M, _,_,_),
C12 = s(M,C13,_,_),
C11 = s(M,C12,_,_).
% 1-2-4
p1(M,s(M,_,s(M,_,_,C11),s(M,_,C11,s(M,_,C12,s(M,_,C13,_))))) :-
C13 = s(M,_,_, _),
C12 = s(M,_,_,C13),
C11 = s(M,_,_,C12).
/*
p1(M,C00) :- % 4-2-1
C00 = s(M,C01,C10,_), C10 = s(M,C11,_,_),
C01 = s(M,C02,C11,_), C11 = s(M,C12,_,_),
C02 = s(M,C03,C12,_), C12 = s(M,C13,_,_),
C03 = s(M, _,C13,_), C13 = s(M, _,_,_).
p1(M,C00) :- % 2-1-4
C00 = s(M,C10,_,C01), C10 = s(M,_,_,C11),
C01 = s(M,C11,_,C02), C11 = s(M,_,_,C12),
C02 = s(M,C12,_,C03), C12 = s(M,_,_,C13),
C03 = s(M,C13,_, _), C13 = s(M,_,_, _).
p1(M,C00) :- % 1-4-2
C00 = s(M,_,C01,C10), C10 = s(M,_,C11,_),
C01 = s(M,_,C02,C11), C11 = s(M,_,C12,_),
C02 = s(M,_,C03,C12), C12 = s(M,_,C13,_),
C03 = s(M,_, _,C13), C13 = s(M,_, _,_).
p1(M,C00) :- % 2-4-1
C00 = s(M,C10,C01,_), C10 = s(M,_,C11,_),
C01 = s(M,C11,C02,_), C11 = s(M,_,C12,_),
C02 = s(M,C12,C03,_), C12 = s(M,_,C13,_),
C03 = s(M,C13, _,_), C13 = s(M,_, _,_).
p1(M,C00) :- % 4-1-2
C00 = s(M,C01,_,C10), C10 = s(M,C11,_,_),
C01 = s(M,C02,_,C11), C11 = s(M,C12,_,_),
C02 = s(M,C03,_,C12), C12 = s(M,C13,_,_),
C03 = s(M, _,_,C13), C13 = s(M, _,_,_).
p1(M,C00) :- % 1-2-4
C00 = s(M,_,C10,C01), C10 = s(M,_,_,C11),
C01 = s(M,_,C11,C02), C11 = s(M,_,_,C12),
C02 = s(M,_,C12,C03), C12 = s(M,_,_,C13),
C03 = s(M,_,C13, _), C13 = s(M,_,_, _).
*/
% p2 = 3x1x1: 3 orientations
p2(M,s(M,s(M,s(M,_,_,_),_,_),_,_)).
p2(M,s(M,_,s(M,_,s(M,_,_,_),_),_)).
p2(M,s(M,_,_,s(M,_,_,s(M,_,_,_)))).
%p2(C00,M) :- C00 = s(M,C01,_,_), C01 = s(M,C02,_,_), C02 = s(M,_,_,_).
%p2(C00,M) :- C00 = s(M,_,C01,_), C01 = s(M,_,C02,_), C02 = s(M,_,_,_).
%p2(C00,M) :- C00 = s(M,_,_,C01), C01 = s(M,_,_,C02), C02 = s(M,_,_,_).
% p3 = 2x2x1: 3 orientations
p3(M,s(M,s(M,_,C,_),s(M,C,_,_),_)) :- % 2-2-1
C = s(M,_,_,_).
p3(M,s(M,s(M,_,_,C),_,s(M,C,_,_))) :- % 2-1-2
C = s(M,_,_,_).
p3(M,s(M,_,s(M,_,_,C),s(M,_,C,_))) :- % 1-2-2
C = s(M,_,_,_).
%p3(M,C00) :- % 2-2-1
% C00 = s(M,C10,C01,_), C10 = s(M,_,C11,_),
% C01 = s(M,C11, _,_), C11 = s(M,_, _,_).
%p3(M,C00) :- % 1-2-2
% C00 = s(M,_,C10,C01), C10 = s(M,_,_,C11),
% C01 = s(M,_,C11, _), C11 = s(M,_,_, _).
% p4 = 2x2x2: 1 orientation
p4(M,s(M,s(M,_,C110,C101),s(M,C110,_,s(M,C111,_,_)),s(M,C101,C011,_))) :-
C110 = s(M, _, _,C111),
C101 = s(M, _,C111, _),
C011 = s(M,C111, _, _),
C111 = s(M, _, _, _).
/*
p4(M,C000) :-
C000 = s(M,C100,C010,C001),
C100 = s(M, _,C110,C101),
C010 = s(M,C110, _,C011),
C110 = s(M, _, _,C111),
C001 = s(M,C101,C011, _),
C101 = s(M, _,C111, _),
C011 = s(M,C111, _, _),
C111 = s(M, _, _, _).
*/
make_board(Level0) :-
make_level(Level0-Level1,Level1-_),
make_level(Level1-Level2,Level2-_),
make_level(Level2-Level3,Level3-_),
make_level(Level3-Level4,Level4-_),
make_level(Level4-[],[ z,z,z,z,z,
z,z,z,z,z,
z,z,z,z,z,
z,z,z,z,z,
z,z,z,z,z]-[]).
make_level(C-Link,Z-L) :-
C= [C00,C10,C20,C30,C40,
C01,C11,C21,C31,C41,
C02,C12,C22,C32,C42,
C03,C13,C23,C33,C43,
C04,C14,C24,C34,C44|Link],
Z= [Z00,Z10,Z20,Z30,Z40,
Z01,Z11,Z21,Z31,Z41,
Z02,Z12,Z22,Z32,Z42,
Z03,Z13,Z23,Z33,Z43,
Z04,Z14,Z24,Z34,Z44|L],
C00 = s(_,C10,C01,Z00),
C10 = s(_,C20,C11,Z10),
C20 = s(_,C30,C21,Z20),
C30 = s(_,C40,C31,Z30),
C40 = s(_, z,C41,Z40),
C01 = s(_,C11,C02,Z01),
C11 = s(_,C21,C12,Z11),
C21 = s(_,C31,C22,Z21),
C31 = s(_,C41,C32,Z31),
C41 = s(_, z,C42,Z41),
C02 = s(_,C12,C03,Z02),
C12 = s(_,C22,C13,Z12),
C22 = s(_,C32,C23,Z22),
C32 = s(_,C42,C33,Z32),
C42 = s(_, z,C43,Z42),
C03 = s(_,C13,C04,Z03),
C13 = s(_,C23,C14,Z13),
C23 = s(_,C33,C24,Z23),
C33 = s(_,C43,C34,Z33),
C43 = s(_, z,C44,Z43),
C04 = s(_,C14, z,Z04),
C14 = s(_,C24, z,Z14),
C24 = s(_,C34, z,Z24),
C34 = s(_,C44, z,Z34),
C44 = s(_, z, z,Z44).
/*
portray(board(Board)) :- !,write_board(Board),!.
portray([s(V,_,_,_)|T]) :- !,write_board([s(V,_,_,_)|T]),!.
portray(s(V,_,_,_)) :- !,write(s(V)),!.
write_board(Board) :-
nl,write_board(Board,0),nl.
write_board(V,_) :-
var(V),!,write(V).
write_board([],_).
write_board([s(V,_,_,_)|T],N) :-
(N mod 5 =\= 0 ; write(' ')),
(N mod 25 =\= 0 ; nl),
(var(V) -> write('_') ; write(V)),
N1 is N+1,
write_board(T,N1).
*/
*** First FCP program:
%------------------------------------------------------------------------------
% Benchmark Program - Puzzle (Quintus Prolog Version)
% Lisp vs. Prolog Study
%
% Copyright by Evan Tick
% Date: October 30 1985
%
% Adapted to Typed FCP by Ehud Shapiro, December 21st, 1987.
% Multiprocessor version, depth first search using
% the recomputation strategy.
%
% To execute:
% board#make_board(BoardIndex,Board) :- to compute Board.
%
% run(BoardIndex,N,Board,Queries) :- to solve with N processors.
% To find the current number of trials during execution, send the query:
% Queries=[trial(T↑)|Queries1].
%------------------------------------------------------------------------------
-language(typed_fcp).
-syntax(typed_fcp).
-mode(trust).
-export([run/4,queue/3]).
Board ::= board#Board.
BoardIndex ::= board#BoardIndex.
Id ::= board#Id.
Cell ::= board#Cell.
InitialBoard ::= board#InitialBoard.
FrozenBoard ::= String.
Restart ::= restart(FrozenBoard,Pieces).
Pieces ::= [PiecesOfAKind|[PiecesOfAKind]].
PiecesOfAKind ::= [Id|[Id]].
Move ::= Integer ; last.
MoveAttempt ::= Move ; failed.
Path ::= [Move].
Trail ::= [Move].
Continuation ::= Integer.
Trial ::= Integer.
Processors ::= Integer.
ToQueue ::= [QueueRequest|[QueueRequest]].
EnQDeQ ::=
enqueue(QueueElement) ;
dequeue(QueueElement).
QueueRequest ::=
EnQDeQ ;
solution;
trial(Trial).
ToQueueMerger ::= [QueueMergerRequest] ; None.
QueueMergerRequest ::= QueueRequest ; merge(ToQueue).
QueueElement ::= (Path,Continuation).
Queue ::= [EnQDeQ].
procedure run(BoardIndex,Processors,Board,Integer).
run(BoardIndex,Processors,Board,ToQueue1) :-
freeze#freeze(Board,FrozenBoard,_),
pieces(BoardIndex,Pieces),
processors(Processors,restart(FrozenBoard?,Pieces),ToQueueMerger),
stream#merger([merge(ToQueue1)|ToQueueMerger],ToQueue),
initial_continuation(BoardIndex?,QueueElement),
queue([enqueue(QueueElement)|ToQueue],[],0).
procedure initial_continuation(BoardIndex,QueueElement).
initial_continuation(1,([],1)).
initial_continuation(5,([1,0,0,0],1)). % first move fixed.
procedure pieces(BoardIndex,Pieces).
pieces(1,[[a],[m,n,o,p],[],[]]).
pieces(5,[[a,b,c,d,e,f,g,h,i,j,k,l,m],[n,o,p],[q],[r]]).
procedure queue(ToQueue,Queue,Trial).
queue([dequeue(X)|In],[enqueue(X)|Queue],Trial) :-
queue(In?,Queue,Trial?).
queue([dequeue(X)|In],Queue,Trial) :-
otherwise | % Queue empty or first request is dequeue(_).
queue(In?,[dequeue(X)|Queue],Trial).
queue([enqueue(X)|In],[dequeue(X)|Queue],Trial) :-
queue(In?,Queue,Trial).
queue([enqueue(X)|In],Queue,Trial) :-
otherwise | % Queue empty or first request is enqueue(_).
queue(In?,[enqueue(X)|Queue],Trial).
queue([trial|In],Queue,Trial) :-
Trial1 := Trial+1,
queue(In?,Queue,Trial1?).
queue([solution|In],Queue,Trial) :-
screen#display(solution_after(Trial)).
queue([trial(Trial)|In],Queue,Trial) :-
queue(In?,Queue,Trial).
procedure processors(Processors,Restart,ToQueueMerger).
processors(0,_,[]).
processors(N,Restart,[merge(ToQueue)|ToQueue1]) :-
N>0 |
processor(ToQueue,Restart), % @here
N1:=N-1,
processors(N1?,Restart,ToQueue1). % @next
procedure processor(ToQueue,Restart).
processor([dequeue((Path,Cont))|ToQ],restart(FrozenBoard,Pieces)) :-
freeze#melt(FrozenBoard,Board,_),
trace(Path?,Board?,Pieces?,Cont?,Path,restart(FrozenBoard?,Pieces),ToQ).
procedure trace(Path,InitialBoard,Pieces,Continuation,Path,Restart,ToQueue).
trace([Move|Moves],[Spot|Rest],Pieces,Cont,Path,Restart,ToQ) :-
Move =\= 0 |
fill(Move,0,Spot,Pieces,NewPieces),
trace(Moves?,Rest,NewPieces,Cont,Path,Restart,ToQ).
trace([0|Moves],[Spot|Rest],Pieces,Cont,Path,Restart,ToQ) :-
trace(Moves?,Rest,Pieces,Cont,Path,Restart,ToQ).
trace([],[Spot|Rest],Pieces,Cont,Path,Restart,ToQ) :-
fill(Move,Cont,Spot,Pieces,NewPieces),
continue(Move?,Rest,NewPieces,Path,[],Restart,ToQ).
procedure continue(MoveAttempt,Board,Pieces,Path,Trail,Restart,ToQueue).
continue(failed,Rest,NewPieces,Path,Trail,Restart,ToQ) :-
processor(ToQ,Restart).
continue(last,Rest,NewPieces,Path,Trail,Restart,ToQ) :-
explore(Rest,NewPieces,Path,[last|Trail],Restart,ToQ).
continue(Move,Rest,NewPieces,Path,Trail,Restart,
[enqueue((NewPath?,Cont?))|ToQ]
) :-
Move =\= failed, Move =\= last |
Cont := Move+1,
append_reverse(Path?,Trail?,NewPath),
explore(Rest,NewPieces?,Path,[Move|Trail],Restart,ToQ).
procedure explore(Board,Pieces,Path,Trail,Restart,ToQueue).
explore([],_,_,_,Restart,[solution|ToQ]). % Thats's it for me.
explore([{V,_,_,_}|Rest],Pieces,Path,Trail,Restart,ToQ) :-
% spot already filled
known(V) |
explore(Rest?,Pieces,Path,[0|Trail],Restart,ToQ).
explore([{V?,X,Y,Z}|Rest],Pieces,Path,Trail,Restart,[trial|ToQ]) :-
% spot empty - try to fill
fill(Move,0,{V,X,Y,Z},Pieces,NewPieces),
continue(Move?,Rest,NewPieces?,Path,Trail,Restart,ToQ).
procedure fill(MoveAttempt,Continuation,Cell,Pieces,Pieces).
% p1 = 4x2x1: 6 orientations
fill(1,Cont,{M,{M,{M,{M,_,C13,_},C12,_},C11,_},{M,C11,_,_},_},
[[M|P1]|T],[P1|T]) :- % 4-2-1
Cont=<1,
C13 = {M, _,_,_},
C12 = {M,C13,_,_},
C11 = {M,C12,_,_} | true.
fill(2,Cont,{M,{M,_,_,C11},_,{M,C11,_,{M,C12,_,{M,C13,_,_}}}},
[[M|P1]|T],[P1|T]) :- % 2-1-4
Cont=<2,
C13 = {M,_,_, _},
C12 = {M,_,_,C13},
C11 = {M,_,_,C12} | true.
fill(3,Cont,{M,_,{M,_,{M,_,{M,_,_,C13},C12},C11},{M,_,C11,_}},
[[M|P1]|T],[P1|T]) :- % 1-4-2
Cont=<3,
C13 = {M,_, _,_},
C12 = {M,_,C13,_},
C11 = {M,_,C12,_} | true.
fill(4,Cont,{M,{M,_,C11,_},{M,C11,{M,C12,{M,C13,_,_},_},_},_},
[[M|P1]|T],[P1|T]) :- % 2-4-1
Cont=<4,
C13 = {M,_, _,_},
C12 = {M,_,C13,_},
C11 = {M,_,C12,_} | true.
fill(5,Cont,{M,{M,{M,{M,_,_,C13},_,C12},_,C11},_,{M,C11,_,_}},
[[M|P1]|T],[P1|T]) :- % 4-1-2
Cont=<5,
C13 = {M, _,_,_},
C12 = {M,C13,_,_},
C11 = {M,C12,_,_} | true.
fill(6,Cont,{M,_,{M,_,_,C11},{M,_,C11,{M,_,C12,{M,_,C13,_}}}},
[[M|P1]|T],[P1|T]) :- % 1-2-4
Cont=<6,
C13 = {M,_,_, _},
C12 = {M,_,_,C13},
C11 = {M,_,_,C12} | true.
% p2 = 3x1x1: 3 orientations
fill(7,Cont,{M,{M,{M,_,_,_},_,_},_,_},[P1,[M|P2]|T],[P1,P2|T]) :-
Cont=<7 | true.
fill(8,Cont,{M,_,{M,_,{M,_,_,_},_},_},[P1,[M|P2]|T],[P1,P2|T]) :-
Cont=<8 | true.
fill(9,Cont,{M,_,_,{M,_,_,{M,_,_,_}}},[P1,[M|P2]|T],[P1,P2|T]) :-
Cont=<9 | true.
% p3 = 2x2x1: 3 orientations
fill(10,Cont,{M,{M,_,C,_},{M,C,_,_},_},[P1,P2,[M|P3]|T],[P1,P2,P3|T]) :-
Cont=<10,
C = {M,_,_,_} | true.
fill(11,Cont,{M,{M,_,_,C},_,{M,C,_,_}},[P1,P2,[M|P3]|T],[P1,P2,P3|T]) :-
Cont=<11,
C = {M,_,_,_} | true.
fill(12,Cont,{M,_,{M,_,_,C},{M,_,C,_}},[P1,P2,[M|P3]|T],[P1,P2,P3|T]) :-
Cont=<12,
C = {M,_,_,_} | true.
% p4 = 2x2x2: 1 orientation
fill(last,Cont,{M,{M,_,C110,C101},{M,C110,_,{M,C111,_,_}},{M,C101,C011,_}},
[P1,P2,P3,[M|P4]|T],[P1,P2,P3,P4|T]) :-
Cont=<13,
C110 = {M, _, _,C111},
C101 = {M, _,C111, _},
C011 = {M,C111, _, _},
C111 = {M, _, _, _} | true.
fill(failed,Cont,Spot,P,P) :-
otherwise | true.
% Note: literally speaking, there is a need for 'otherwise' in every
% clause, to ensure sequential clause try.
procedure append_reverse([Any],[Any],[Any]).
append_reverse([X|Xs],Ys,[X|Zs]) :-
append_reverse(Xs?,Ys,Zs).
append_reverse([],Ys,Zs) :-
reverse(Ys?,[],Zs).
procedure reverse([Any],[Any],[Any]).
reverse([],Ys,Ys).
reverse([X|Xs],Ys,Zs) :-
reverse(Xs?,[X|Ys],Zs).
*** Seconds FCP program:
%------------------------------------------------------------------------------
% Benchmark Program - Puzzle (Quintus Prolog Version)
% Lisp vs. Prolog Study
%
% Copyright by Evan Tick
% Date: October 30 1985
%
% Adapted to Typed FCP by Ehud Shapiro, December 21st, 1987.
% Multiprocessor version, depth first search.
% Brute force method (freeze state in each choice point).
% To execute:
% run(BoardIndex,N,Board,Queries)
%------------------------------------------------------------------------------
-syntax(typed_fcp).
-language(typed_fcp).
-mode(trust).
-export([run/4]).
Board ::= board#Board.
BoardIndex ::= board#BoardIndex.
Id ::= board#Id.
Cell ::= board#Cell.
InitialBoard ::= board#InitialBoard.
FrozenBoard ::= String.
State ::= (FrozenBoard,Pieces,Continuation).
Pieces ::= [PiecesOfAKind|[PiecesOfAKind]].
PiecesOfAKind ::= [Id|[Id]].
Move ::= Integer ; last.
MoveAttempt ::= Move ; failed.
Path ::= [Move].
Trail ::= [Move].
Continuation ::= Integer.
Trial ::= Integer.
Processors ::= Integer.
ToQueue ::= [QueueRequest|[QueueRequest]].
EnQDeQ ::=
enqueue(QueueElement) ;
dequeue(QueueElement).
QueueRequest ::=
EnQDeQ ;
solution ;
trial ;
trial(Trial).
ToQueueMerger ::= [QueueMergerRequest].
QueueMergerRequest ::= QueueRequest ; merge(ToQueue).
QueueElement ::= State.
Queue ::= [EnQDeQ].
procedure run(BoardIndex,Processors,Board,Integer).
run(BoardIndex,Processors,Board,ToQueue1) :-
freeze#freeze(Board,FrozenBoard,_),
pieces(BoardIndex,Pieces),
processors(Processors,ToQueueMerger),
stream#merger([merge(ToQueue1)|ToQueueMerger],ToQueue),
QueueElement=(FrozenBoard,Pieces,0),
puzzle8#queue([enqueue(QueueElement)|ToQueue],[],0).
procedure pieces(BoardIndex,Pieces).
pieces(1,[[a],[m,n,o,p],[],[]]).
pieces(5,[[a,b,c,d,e,f,g,h,i,j,k,l,m],[n,o,p],[q],[r]]).
procedure processors(Processors,ToQueueMerger).
processors(0,[]).
processors(N,[merge(ToQueue)|ToQueue1]) :-
N>0 |
processor(ToQueue), % @here
N1:=N-1,
processors(N1?,ToQueue1). % @next
procedure processor(ToQueue).
processor([dequeue((FrozenBoard,Pieces,Cont))|ToQ]) :-
freeze#melt(FrozenBoard,Board,_),
Board? = [Spot|Rest],
fill(Move,Cont?,Spot?,Pieces,NewPieces),
continue(Move?,Rest,NewPieces,FrozenBoard,Pieces,ToQ).
procedure continue(MoveAttempt,Board,Pieces,FrozenBoard,Pieces,ToQueue).
continue(failed,Rest,NewPieces,FrozenBoard,Pieces,ToQ) :-
processor(ToQ).
continue(last,Rest,NewPieces,FrozenBoard,Pieces,ToQ) :-
explore(Rest,NewPieces,ToQ).
continue(Move,Rest,NewPieces,FrozenBoard,Pieces,
[enqueue((FrozenBoard?,Pieces,Cont?))|ToQ]
) :-
Move =\= failed, Move =\= last |
Cont := Move+1,
explore(Rest,NewPieces?,ToQ).
procedure explore(Board,Pieces,ToQueue).
explore([],_,[solution|ToQ]). % That's it for me.
explore([{V,_,_,_}|Rest],Pieces,ToQ) :-
% spot already filled
known(V) |
explore(Rest?,Pieces,ToQ).
explore(Board,Pieces,[trial|ToQ]) :-
% spot empty - try to fill
Board = [{V,X,Y,Z}|Rest],
unknown(V) |
freeze#freeze(Board,FrozenBoard,_),
wait_then_continue(FrozenBoard?,Board,Pieces,ToQ).
wait_then_continue(FrozenBoard,[{V,X,Y,Z}|Rest],Pieces,ToQ) :-
known(FrozenBoard) |
fill(Move,0,{V,X,Y,Z},Pieces,NewPieces),
continue(Move?,Rest,NewPieces?,FrozenBoard,Pieces,ToQ).
procedure fill(MoveAttempt,Continuation,Cell,Pieces,Pieces).
% (same is in puzzle8)
*** Utility program:
%------------------------------------------------------------------------------
% Benchmark Program - Puzzle (Quintus Prolog Version)
% Lisp vs. Prolog Study
%
% Copyright by Evan Tick
% Date: October 30 1985
%
% Adapted to Typed FCP by Ehud Shapiro, December 21st, 1987.
%
% To execute:
% make_board(BoardIndex,Board) :- to compute Board, BoardIndex ::= 1 ; 5.
%------------------------------------------------------------------------------
-module(board).
-syntax(typed_fcp).
-language(typed_fcp).
-export([make_board/2]).
Cell ::= {Id,CellPointer,CellPointer,CellPointer}.
Id ::= String.
CellPointer ::= Cell ; z.
Board ::= [Cell].
InitialBoard ::= [Cell|Board]. % nonempty.
BoardIndex ::= 1 ; 5.
procedure make_board(Integer,Board).
make_board(1,Level0) :-
make_level4x5(Level0-[],[ z,z,z,z,z,
z,z,z,z,z,
z,z,z,z,z,
z,z,z,z,z]-[]).
procedure make_board(BoardIndex,Board).
make_board(5,Level0) :-
make_level(Level0-Level1,Level1-_),
make_level(Level1-Level2,Level2-_),
make_level(Level2-Level3,Level3-_),
make_level(Level3-Level4,Level4-_),
make_level(Level4-[],[ z,z,z,z,z,
z,z,z,z,z,
z,z,z,z,z,
z,z,z,z,z,
z,z,z,z,z]-[]).
make_board(1,Level0) :-
make_level4x5(Level0-[],[ z,z,z,z,z,
z,z,z,z,z,
z,z,z,z,z,
z,z,z,z,z]-[]).
procedure make_level(Board-[CellPointer],[CellPointer]-[CellPointer]).
make_level(C-Link,Z-L) :-
C= [C00,C10,C20,C30,C40,
C01,C11,C21,C31,C41,
C02,C12,C22,C32,C42,
C03,C13,C23,C33,C43,
C04,C14,C24,C34,C44|Link],
Z= [Z00,Z10,Z20,Z30,Z40,
Z01,Z11,Z21,Z31,Z41,
Z02,Z12,Z22,Z32,Z42,
Z03,Z13,Z23,Z33,Z43,
Z04,Z14,Z24,Z34,Z44|L],
C00 = {_,C10,C01,Z00},
C10 = {_,C20,C11,Z10},
C20 = {_,C30,C21,Z20},
C30 = {_,C40,C31,Z30},
C40 = {_, z,C41,Z40},
C01 = {_,C11,C02,Z01},
C11 = {_,C21,C12,Z11},
C21 = {_,C31,C22,Z21},
C31 = {_,C41,C32,Z31},
C41 = {_, z,C42,Z41},
C02 = {_,C12,C03,Z02},
C12 = {_,C22,C13,Z12},
C22 = {_,C32,C23,Z22},
C32 = {_,C42,C33,Z32},
C42 = {_, z,C43,Z42},
C03 = {_,C13,C04,Z03},
C13 = {_,C23,C14,Z13},
C23 = {_,C33,C24,Z23},
C33 = {_,C43,C34,Z33},
C43 = {_, z,C44,Z43},
C04 = {_,C14, z,Z04},
C14 = {_,C24, z,Z14},
C24 = {_,C34, z,Z24},
C34 = {_,C44, z,Z34},
C44 = {_, z, z,Z44}.
procedure make_level4x5(Board-[CellPointer],[CellPointer]-[CellPointer]).
make_level4x5(C-Link,Z-L) :-
C= [C01,C11,C21,C31,C41,
C02,C12,C22,C32,C42,
C03,C13,C23,C33,C43,
C04,C14,C24,C34,C44|Link],
Z= [Z01,Z11,Z21,Z31,Z41,
Z02,Z12,Z22,Z32,Z42,
Z03,Z13,Z23,Z33,Z43,
Z04,Z14,Z24,Z34,Z44|L],
C01 = {_,C11,C02,Z01},
C11 = {_,C21,C12,Z11},
C21 = {_,C31,C22,Z21},
C31 = {_,C41,C32,Z31},
C41 = {_, z,C42,Z41},
C02 = {_,C12,C03,Z02},
C12 = {_,C22,C13,Z12},
C22 = {_,C32,C23,Z22},
C32 = {_,C42,C33,Z32},
C42 = {_, z,C43,Z42},
C03 = {_,C13,C04,Z03},
C13 = {_,C23,C14,Z13},
C23 = {_,C33,C24,Z23},
C33 = {_,C43,C34,Z33},
C43 = {_, z,C44,Z43},
C04 = {_,C14, z,Z04},
C14 = {_,C24, z,Z14},
C24 = {_,C34, z,Z24},
C34 = {_,C44, z,Z34},
C44 = {_, z, z,Z44}.
------------------------------
End of PROLOG Digest
********************
∂02-Jan-88 0120 @Score.Stanford.EDU:FEIGENBAUM@SUMEX-AIM.Stanford.EDU On royalties and Royalty (long message)
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Jan 88 01:20:48 PST
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sat 2 Jan 88 01:18:38-PST
Date: Sat, 2 Jan 88 01:19:08 PST
From: Edward Feigenbaum <FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
Subject: On royalties and Royalty (long message)
To: ac@score.Stanford.EDU
Message-ID: <12363337116.12.FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
Summary
Nils has proposed a change in current department policy
regarding the assignment of royalty revenue to research
projects. The current policy was put in place to provide
incentive for developers (faculty and staff) to contribute
their personal shares to their research projects and thereby
provide significant amounts of unrestricted funds for
projects to help them through financial difficulties--
something the department is not able to do. We are now
facing a period of potentially great funding stresses
for projects, so at the very least the timing of the
proposed policy change is bad. But beyond such near-term
considerations is a political dimension--a question of the
power of the central departmental administration vs the
largely decentralized model with which we have been
operating.
My own view is negative on the policy change. The incentive
needs to remain in place; the research projects have a major
need for the unrestricted funds generated thereby; and the
power shift to "central" that is implicit in the money shift
is a bad precedent.
Background
When royalties flow to the university from a patent or a
copyright, a formula divides up the royalties. The
university assigns about 28% to the department and an equal
amount to the creators of the idea or material. In 1980,
during my chairmanship, the department discussed and passed
a policy that assigned the department's share to the
research project of the creators IF the creators themselves
assigned their share to their research project (instead of
taking the money for themselves). In this way, about 56% of
royalties could be made available to unrestricted funds of
projects.
Why did we do this? Let me review briefly the thinking of
the time.
Research projects were thought to be in a difficult position
financially. The department had no operating funds to
provide research support for them, not even the full-time
salary of faculty members (as is the custom in some other
departments). The projects are at the mercy of (mostly)
federal funding agencies, whose budgets fluctuate and whose
personnel and peer reviewers sometimes make their judgements
based on changing fashion and whim. The occasional corporate
sponsor often gives wildly fluctuating support for similar
reasons.
Research projects have no financial buffer other than their
unrestricted funds and gifts. These funds provide very
little insurance against funding adversity. Funds are often
needed to bridge between successive grants/contracts because
circumstances that are adverse and unexpected often happen.
Funds are also needed to cover peculiar operational needs
that the department can not and will not cover. (For
example, a staff scientist departs as planned at the end of
a grant but there is an "accrued vacation" that has to be
paid in real money; but no one planned for THAT, the grant
funds are gone, and alas the unrestricted funds need to be
tapped. Sound familiar?) CSD is the backstop of last resort
but has never had the funds to play this role, and in the
governance model we have used has never seen its role to be
this.
In the debates of 1980, another important consideration was
heightened incentive for individuals to contribute their
royalty shares to their projects. As with biology
departments, there was the prospect of spinoff companies to
exploit developments of our research work, and the question
was how to provide enough incentives to induce our people to
work within our system, licensing the developments and
paying royalties. It was obviously feasible for people to
simply take the technology "across the street" (to use the
jargon of the time) without acknowledgment of their debt to
Stanford (in form of royalty payments). The very same people
who had developed the technology here were participating in
the ventures, and they had the necessary knowledge in their
heads to duplicate the work in an "improved" or slightly
different form. Stanford's rights in these developments were
the object of much bitter debate around the campus at the
time, but were tenuous and were difficult to enforce in any
event. In CSD, we sought to avoid the hard feelings of the
"stick" approach in favor of the "carrot" approach.
Developers (faculty and staff) would be more motivated to
induce their company counterparts to negotiate a license
if the reward to their unrestricted research funds were
approximately one half rather than approximately one
quarter. Though the central department administration would
not benefit thereby (since its share was the carrot), the
projects, and thereby indirectly the students and the
department's quality as a research place, would benefit.
There was another aspect of the incentive that was on our
(collective) mind. Often the developer was not a person but
a team. If some members of the team were inclined to take
their one-Nth of the developers' share, what incentive could
we provide to induce them to leave the money in the research
project. If each of their dollars was indeed worth two if
left in the project, this might provide the needed
incentive.
Our policy seems to have worked out well, and nobody has
asked for a change until Nils' recent memo.
The Current Situation: it is precarious for projects
The department's research projects are heading into
difficult financial times, with possibly extreme budget cuts
in the offing. There are several converging reasons for
this. The federal budget will be under severe downward
pressure as congress wrestles with the deficit. If congress
does nothing, the Gramm-Rudman cuts will automatically take
place. Research money is seen as "discretionary" and is
often hard hit in times like these. Secondly, the DOD
funding sources that have historically given us so much
funding, are becoming increasingly development funds, or
funds targeted toward some particular applications goal.
Also, big chunks of research money are being "targeted"
for large centers (like the NSF centers), for national
networking (like NSFnet and its proposed major expansion),
and for supercomputer centers. It may sound as if these
things are hypothetical and in the future, but actually most
of us already have some war story to tell about the current
funding problems. In my case, one major project budget
received a significant, but not fatal, cut; and our largest
budget, for which renewal is soon to be proposed, is
severely threatened.
As lean years approach, the research projects need help to
build stores of funding. Because of the contraints of its
own operating budget, which is in deficit anyway, and
because of our traditional governance model and its
associated policies, the department is really not in a
position to help much. Nils' proposal to change the current
policy on assignment of royalty funds is anti-help.
In his memo, Nils uses the example of CMU where (in
mythology, at least) the research projects cede some of
their funds to the centralized CSD administration for the
good of the department and that administration in turn does
good things with the money. The analogy with the Stanford
situation is not apt because at CMU the relationship between
"central" and projects is symmetrical: projects cede some of
their autonomy, but in return the "central" takes care of
them financially when they run into trouble. We don't have
that situation here.
Let me conclude this section with an example of our current
situation, a personal example. More than a year ago, I
discovered that a major Japanese company was selling a
developed version of a big piece of software done at the
Heuristic Programming Project in the late '70s, without
having contacted Stanford for a license. I worked hard to
turn this situation around retroactively. I visited the
company management in Japan and made the best case that I
could to persuade them to negotiate the license. I told them
that in addition to doing what was legally right and morally
right, they would be contributing research funds to a lab
that they respect. It took a year to get their signature on
a license, with a one-time royalty payment of $50K, but we
did it. And ironically the good news about this (albiet
small amount) was coming at the same time as the bad news
about the delay in one corporate source of funding, the
demise of another, the gathering black cloud over DARPA
funding. Oh, yes. And Nils' memo, threatening even the small
amount of the victory. And I sit here during the vacation
writing this memo during a time-out from writing the
aforementioned renewal proposal that is in trouble even
before I write it.
The Political Dimension to the issue raised by Nils
Beyond the specifics of Nils' proposal lies a political
issue of importance. I've alluded to it earlier. It involves
our most basic view of the governance of our department.
Sorry to use such a fancy word, but what I mean is our
fundamental model of how our department should operate.
Do we want to move in the direction of a "centralist"
governing model, sometimes called a "federal" model? Or
are we comfortable with the decentralized model that we now
have, in which the department administration's role is by
tradition and policy circumscribed? Our current model has
its pains but it also has its gains.
Boiled down to its essense, what Nils' memo says is:
"central" needs and wants more money (and incidentally it
sees royalties as a source). But centralized governments
always want more money. They always can give plausible
reasons for the need and the socially important uses to
which the money will be put. There are always more of these
than there is money. For example, Nils' memo expresses the
"need" for more money to support first year graduate
students--not the first time we have heard him express this
view. But that is HIS goal and not necessarily our
(collective) goal. Why should we fund this goal indirectly
by virtue of the proposed redirection of money to "central"?
Suppose we go along with this proposal? What goals, or
personal inclinations, will future chairmen have? I suggest
that we not fund these in advance, so to speak, by a basic
change in our governance model, but rather consider each as
it comes up. We can always move unrestricted funds back to
"central" if we choose to, but if they aren't in our hands,
then we can't decide to. The use will be decided for us.
In short, the political dimension is this:
money is power, and this play for more money is to be seen
as a play for more power. (No, I'm not suggesting that Nils
craves power, but simply that he wants the department to
"do more things").
Conclusion
I urge a "no" vote on Nils' royalty proposal. The present
policy has been working well. Research projects are facing
difficult times. Now is not the time for "central" to take
unrestricted funds away from them, if indeed there ever is
an appropriate time for such a taking. The incentive for
developers to contribute their own royalties has been
useful. None of the underlying reasons that motivated our
present policy have changed. The only change is that Nils
says the department needs more money to do some good things.
In my view, the power shift that accompanies the money shift
is, anyway, a bad precedent.
-------
∂02-Jan-88 0953 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu 1987 Summary/1988 Prospectus
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Jan 88 09:53:02 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Sat 2 Jan 88 09:37:41-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA05890; Sat, 2 Jan 88 09:38:10 PST
Date: Sat, 2 Jan 88 09:38:10 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8801021738.AA05890@Tenaya.stanford.edu>
To: csd-list@score
Subject: 1987 Summary/1988 Prospectus
Dear faculty, staff, students and friends of computer science at Stanford:
I've gotten into the habit of summarizing the state of Stanford's
Computer Science Department at the end of each calendar year---this
one marks my third full year at Stanford. (Some chairmanships rotate
after three years; I promised to stay at it for five years plus a
couple of quarters, and I'm glad to say that I haven't quite run out
of gas yet!)
Probably the most important thing to say about us at the end of 1987
is that we are a rather different faculty than we were at the
beginning of 1985. Since I arrived, five of our faculty (occupying 3
1/2 billets) have left and six new ones (occupying 6 billets) have
arrived. Approximately 25% of our current faculty roster have joined
us since I arrived. We have offers out to two new faculty members and
are currently searching for three more, so we'll be even more
different in another two years or so. Such rapid change creates some
special problems and opportunities for us. We want to maintain the
traditions that make us first-rate while benefiting from the ideas and
energy of our new faculty. In such a setting, it is especially
important for the "old-timers" to take the lead in developing
productive collegial relationships with our new people. I'm very
happy about the fact that there are already several instances in which
these bonds are being formed.
Another thing I like to do at this time is to review the list of
problems that concerned me last year at this time to see what progress,
if any, has been made. Here are the items from last year's message
and a brief comment about each:
1) Integrate the new faculty successfully into the Department.
I hope this is coming along well, but I'd like to hear from any of the
new people about their suggestions.
2) Complete the following searches: two searches for
"programming-language" people; two searches for "foundations"
people; a search for a "scientific computing" person, and a
search for a "systems" person to fill the "CIS" billet.
David Dill fills the "CIS" billet; Andrew Goldberg and John Mitchell
fill the two "foundations" billets (with, additionally, an offer
being made to Janos Komlos); an offer is being made to Roland Glowinski
for the "scientific computing" position; and we are still searching
for a "programming languages" person. (Jim Gibbons has not yet
approved a search for what he calls "billet 6.6"; initially we thought
it might be for a second "programming languages" person, but how the
billet will be used is still undecided.)
3) Exploit the new opportunities for collaboration with CIS
now that a broad-based executive committee is running it.
The CIS executive committee meets biweekly. John Hennessy and I are on
the committee, and I think CIS involves computer science much more now
than it used to. At least one of our faculty (Latombe) has a CIS
seed grant.
4) Continue the campaign to establish additional endowed
professorships.
John McCarthy is now the Charles Pigott Professor of Engineering, and
John Hennessy is the Willard and Inez Bell Professor of Engineering.
5) Get the Near West Campus planning effort to a stage at
which CS will be able to hire an architect and get started on
designing the new building(s).
The "long list" of architects is being pared to a "short list" on
January 11, 1988. (David Cheriton, Mike Genesereth, and I are on the
committee that will help make this selection.) I will invite some of
the architects to one of our faculty lunches this quarter. All who
want to participate in talking with short-list candidates will be able
to do so. Stanford's Board of Trustees have given concept approval
for the information sciences complex which will house Computer Science
(including CSL) and E.E.'s Information Systems Lab.
6) Begin the campaign for adequate funds for the new
building(s).
The Dean's office and the Development office are preparing plans
(including the "mini-labs" idea), and I expect that fund-raising
efforts will greatly accelerate this year.
7) Hire a new Director for CSD-CF.
Welcome Jim Ball!
8) Balance the budget.
(Let's see----what is Reagan's line on this one? I think we
are making progress.)
9) Reverse the downward trend in research support.
Some new contracts and grants did come in last year (including one
to support my research). We wrote quite a large number of proposals,
but prospects for DoD support of truly basic research still look
glum. Struggling for research support will continue to be a problem
for all of us.
Additionally (and briefly) here are some other headlines for the year:
1) Jean-Claude Latombe is adding new energy to robotics efforts
at Stanford. He and Genesereth are collaborating with others to
develop major new robotics programs.
2) David Cheriton was promoted to Associate Professor (with tenure).
3) We established a new interdisciplinary graduate program in
Scientific Computation and Computational Mathematics (SCCM).
4) CSD-CF obtained a new DEC 8700 (named Polya) for educational and
research purposes.
5) The various undergraduate majors in computer science are doing
very well and are attracting large numbers of students.
6) Our affiliates program, the Computer Forum, continues strong and
has expanded to include a special program for smaller companies.
7) Revenues to the Department from our summer educational program
(WICS) and from the Honors Cooperative Program and Television instruction
were higher than expected.
8) Stuart Reges and his staff organized a very successful computer
summer camp at Stanford for high school students.
9) We made some improvements in our administrative organization, hired
some excellent new people to replace several who resigned this year,
and were able to persuade George Wheaton to be our new Associate
Chairman.
10) Carolyn Tajnai produced, with help from many of you, an
outstanding new brochure describing our Department.
11) John Levy and others staged a magnificent Computer Science
alumni event: "The First Ten Years."
12) The Department went through an "internal audit" process. We are
now responding to their report, which (given that it was written by
audit people) confirms my strong belief that the Department's
administration and its practices are sound.
We have a busy year ahead of us. We'll be processing several new
appointments and promotions. We'll be working hard with architects
on our new building plans. We'll interact with a "visiting committee"
in early February. And we'll put a lot of effort into making our
new administrative structure work.
The thing that concerns me most at the beginning of 1988 is that many
of us are really working too hard and are heavily over-extended. As
stresses accumulate, we do an excellent job of putting out
proportionately more effort, but I think we are well into the
"non-linear" range. I'll be the first to admit that the quality of my
work is in danger of deteriorating as the quantity increases. (George
Wheaton will help immensely!) It's very tempting to think that maybe,
after all, a B+ performance will do given that we just can't turn in
an A+ on everything. I'd be most interested to hear from you about
how we can work toward getting ourselves back into the linear range.
If you are one of those who finds himself/herself in this overextended
position, my New Year's message to you is to "just say no" to some of
the things that are contributing to overload (assuming that you are
skilled at judging what's most important.) If you are one of the
few with a little extra capacity, please step up!
I'd like to close by giving a hearty thank you to Anne Richardson, my
secretary, who is leaving Stanford. Anne was extremely efficient and
a joy to work with. I'm afraid my performance on some chairmanship
duties may slip down to a C+ until we find a replacement.
Thank you all for making my job one that gives me a great deal of
pride and satisfaction. Best wishes for a bountiful 1988!
-Nils
∂02-Jan-88 1031 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu royalties, etc.
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Jan 88 10:31:25 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Sat 2 Jan 88 10:28:53-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA05960; Sat, 2 Jan 88 10:29:28 PST
Date: Sat, 2 Jan 88 10:29:28 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8801021829.AA05960@Tenaya.stanford.edu>
To: ac@score
Subject: royalties, etc.
Here's a short response to Ed Feigenbaum's message regarding royalty
income:
1) My suggestion that the Department retain its share of royalty
income (instead of ceding it to research projects) is not an attempt
to increase the power of the central administration. (I am not
on a power trip.) It merely restores the usual rule to what existed
before the policy change instituted during Ed's tenure as chair---a
policy change that I think acted against the best interests of the
commonweal in favor of certain individual research projects.
2) Ed mentions the cloud hanging over research funding as a
justification for ceding these funds to the research projects. Yet
the needs of research projects are large compared to the royalty
funds involved; royalties won't solve the research fund shortage.
They provide non-negligible help however with the smaller needs
for first-year PhD support.
3) I propose to use these funds not for any bureaucratic, central
government-type purposes but to support first-year PhD
students---something the research projects ought to be doing anyway
(but which can be more equitably done on a department-wide basis).
4) The individual may still cede his/her share of the unrestricted
funds to a research project if he/she chooses. The fact that the
individual shares in these royalties provides substantial incentives
to the individual to focus creative energies at Stanford.
5) Large research projects are in a position to exert substantial
pressure on individuals to "go along" with the policy of ceding
royalty income to the project---possibly against the individual's real
wishes.
I urge a vote to abolish the current policy and to return to the
usual system of 1/3 to the School, 1/3 to the Department, and
1/3 to the individual.
-Nils
∂02-Jan-88 1919 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU supercomputing considered harmful
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Jan 88 19:19:27 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sat 2 Jan 88 19:15:27-PST
Date: 02 Jan 88 1909 PST
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: supercomputing considered harmful
To: faculty@SCORE.Stanford.EDU
As everyone knows, there has been big and successful
propaganda for the proposition that what the country
needs to be successful in computing is a collection
of supercomputer centers. According to NSF people,
this has seriously impacted NSF's support for research
in computer science. While the propaganda was going
on, I and, I suppose, most of you stayed out or went
along, hoping to get a few crumbs. I think we need
to study whether spending all that money on supercomputer
centers is cost-effective and how it has impacted
computer science research. There is a new campaign
to increase expenditure on supercomputing by $1.5 billion
in the next five years.
∂03-Jan-88 1030 LOGMTC-request Logic Seminar, Tues. Jan 5
Received: from RUSSELL.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Jan 88 10:19:08 PST
Received: by russell.stanford.edu (3.2/4.7); Sun, 3 Jan 88 10:22:19 PST
Date: Sun 3 Jan 88 10:22:17-PST
From: Sol Feferman <SF@Russell.Stanford.EDU>
Subject: Logic Seminar, Tues. Jan 5
To: logmtc@SAIL.STANFORD.EDU
Message-Id: <568232537.0.SF@Russell.Stanford.EDU>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@Russell.Stanford.EDU>
Speaker: Prof. Girλuseppe Longo, Univ. of Piaλsa and Carnegie-Mellon U.
Title: Modest models and motivatins for λλλλλλλons for impredicative type theory
Time: Tuesday, January 5, 4:15-5:30
Place: Room 383N, Math Corner Stanfordλλλλλλλλλ, Stanford
(3d floor lounge)
Abstract:λλλλλλλλλλ
Abstract: The foundational adequacy of imprediaλcative definitions in
mathematics was the focus of a lively debate in the early years of the
century. Nowadays, polymorphically typed functional programming languages
deal explicitly with impredicative definitions. This applicatiooλn in
computer science, which will shortly be recalled, and recent semantic
investigation of explicit polymorphism contributed to bring the subject
of impredicativity back into the limelight. We will discuss some recent
realizability models and the understanding of impredicative notions
they suggest.
***λλ λ* * *
TλProf λ. Longo will be visiting Stanford for the week Jan.3-Jan.(λ9. This
is getting our seminar in Logic and Foundations off to a good start for
the New Year. We shall continue on the general theme of applications
of logic to computer science. Among the topics to be dealt with are
polymorphism, and proof-verification systems such as NUPRL, PX, Boyer-
Moore, etc.λλλλEKL, etc. We shall also have several visitors speaking on
special topics, among them Masahiko Sato oλλ, Gordon Plotkin and Ian Mason.
There is a possibility to change the time of the seminar if participants
strongly prefer that. That will be discussed after the first meeting.
We hope t o λλλo see you there.
S. Feferman
-------
∂03-Jan-88 1135 @Score.Stanford.EDU:cheriton@pescadero.stanford.edu.stanford.edu On royalties and Royalty (short response)
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Jan 88 11:35:22 PST
Received: from Pescadero by SCORE.STANFORD.EDU with TCP; Sun 3 Jan 88 11:32:47-PST
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA01709; Sun, 3 Jan 88 11:33:21 PST
Date: Sun, 3 Jan 88 11:33:21 PST
From: cheriton@pescadero.stanford.edu.stanford.edu (David Cheriton)
Message-Id: <8801031933.AA01709@Pescadero>
To: FEIGENBAUM@SUMEX-AIM.Stanford.EDU, ac@score.Stanford.EDU
Subject: On royalties and Royalty (short response)
I agree with Ed's position on the proposed change in royalty distribution.
I have been using unrestricted funds and royalties exactly as he describes
for my project and do anticipate some tight times ahead.
I would like to see a fuller discussion of where are dept. funds are going
and prioritize spending, including the 1st year Ph.D. support.
David C.
∂03-Jan-88 1210 @Score.Stanford.EDU:binford@anaconda supercomputing considered harmful
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Jan 88 12:10:21 PST
Received: from anaconda by SCORE.STANFORD.EDU with TCP; Sun 3 Jan 88 12:06:29-PST
Received: by anaconda (3.2/SMI-3.2)
id AA14398; Sun, 3 Jan 88 12:12:16 PST
Date: Sun, 3 Jan 88 12:12:16 PST
From: binford@anaconda (Tom Binford)
Message-Id: <8801032012.AA14398@anaconda>
To: JMC@sail.Stanford.EDU
Cc: faculty@score.Stanford.EDU
Subject: supercomputing considered harmful
John
I share your questioning.
Tom
∂03-Jan-88 1446 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu On royalties and Royalty (short response)
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Jan 88 14:46:12 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Sun 3 Jan 88 14:43:44-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA06732; Sun, 3 Jan 88 14:44:40 PST
Date: Sun, 3 Jan 88 14:44:40 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8801032244.AA06732@Tenaya.stanford.edu>
To: cheriton@pescadero.stanford.edu.stanford.edu
Cc: FEIGENBAUM@SUMEX-AIM.stanford.edu, ac@score.stanford.edu
In-Reply-To: David Cheriton's message of Sun, 3 Jan 88 11:33:21 PST <8801031933.AA01709@Pescadero>
Subject: On royalties and Royalty (short response)
With regard to David's desire to see a fuller description of where
Dept. funds are going, he'll be up to his ears in that starting now---since
he volunteered to be on a finance committee to work with George Wheaton
on analyzing our CSD budget and adherence thereto. George will be
meeting with David and Jeff Ullman (the other budget committee member)
early in Winter Quarter. -Nils
∂04-Jan-88 0026 @Score.Stanford.EDU:cheriton@pescadero.stanford.edu.stanford.edu Re: supercomputing considered harmful
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 00:26:17 PST
Received: from Pescadero by SCORE.STANFORD.EDU with TCP; Mon 4 Jan 88 00:23:23-PST
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA07142; Mon, 4 Jan 88 00:23:59 PST
Date: Mon, 4 Jan 88 00:23:59 PST
From: cheriton@pescadero.stanford.edu.stanford.edu (David Cheriton)
Message-Id: <8801040823.AA07142@Pescadero>
To: JMC@SAIL.Stanford.EDU, faculty@SCORE.Stanford.EDU
Subject: Re: supercomputing considered harmful
Supercomputing is a political invention of the physicists to subvert money
from computer science to physics. Notice the "Office of Scientific Computing"
which basically just buys Crays, etc. for physicists is under the
computer and information sciences directorate. Similarly, all the money that
NSF has for networking research appears to go for phone bills for physicists
to get remote terminal or remote job entry (yes!!) to their supercomputers.
They have also invented "computational sciences" which include the computing
components of physics, chemistry, material science, etc. and of course
computer science - trying to make computer science defined as a set of
computer users, etc. I attended one SIAM meeting where one supposedly
acclaimed physicist pontificated that computer scientists should be working
on assemblers, languages, operating systems, etc. for supercomputers.
I was tempted to retort that at least we had super users (a la Unix) but
the joke would have been lost on this lost audience.
I definitely think there is a need for respected computer scientists to say
that this supercomputer nonsense contributes very little (if anything) to
computer science research. Label it as infrastructure for physics, etc.
and let it be judged under the appropriate priorities.
Unfortunately, I think the problem is political, not technical. Everyone
(except possibly the politicians) know that supercomputing has nothing to do
with computer science so we should not expect the vested interests to listen
to reasoned technical arguments. We need to lobby!
I think it is criminal that NSF provides such limited and questionably
structured and allocated funding for computer science given the importance
of computing in the current and future of the country. If it wasnt for
military funding, the US lead in CS would be lost, if it ever would have
existed, and the Japanese doing a repeat of the VCR story with computers.
Unfortunately, I feel we still have lots to worrry about there, and the enemy
for us is more within the country that outside.
∂04-Jan-88 0121 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V6 #2
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 01:21:18 PST
Date: Sat 2 Jan 1988 08:54-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V6 #2
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Monday, 4 Jan 1988 Volume 6 : Issue 2
Today's Topics:
Query - get0/read & Call,
LP Library - Book
----------------------------------------------------------------------
Date: 30 Dec 87 14:20:58 GMT
From: cos!duc@uunet.uu.net (Duc Kim Nguyen)
Subject: Question on get0/read and call
I have a question concerning get0/read and call (I am using Quintus Prolog):
(1) A predicate f is defined with
:- op(700,fx,f).
(2) A prompt requests input from the terminal:
a) when I use read/1 to get input, eg. f tata, and call/1 on the
input, the call takes place, ie., execution of predicate f occurs
with input tata;
b) when I decided to use the prompt library which uses a loop of get0/1
to build up a list of input, and used atom_chars to convert list
into atom, the call/1 on this term `f tata' resulted in prediciate
'f data' undefined.
Can someone explain to me what the difference between these two cases ?
It seemed the blank made a difference in the two cases ?
------------------------------
Date: 31 Dec 87 12:56:51 GMT
From: linc.cis.upenn.edu!lang@super.upenn.edu (Francois-Michel Lang)
Subject: Question on get0/read and call
I'm not sure I fully understand the question/problem, but I think I
can clear up one apparent misconception: The operator declaration
:- op(700,fx,f).
does NOT define a predicate. It only allows you to use the atom 'f'
as a prefix operator. That sounds like it's part of the problem.
-- Francois-Michel Lang
------------------------------
Date: 31 Dec 87 01:53:00 GMT
From: quintus!ok@sun.com (Richard A. O'Keefe)
Subject: Question on get0/read and call
I'm afraid I don't understand your question. I'll answer what I
*think* is the question you are asking.
(1) An operator declaration doesn't define a predicate.
The operator declaration has nothing to do with what I *think*
your problem is.
(2) As near as I can figure out, you are trying two things.
| ?- read(Goal), call(Goal).
|: f data.
This is the one that works.
| ?- ensure_loaded(library(prompt)),
| prompted_line('Enter goal: ', Chars),
| atom_chars(Atom, Chars),
| call(Atom).
Enter goal: f data
This is the one that doesn't work.
The blank has nothing to do with anything at all.
The answer is this:
The built-in predicate read/1 reads a ***TERM***.
In this particular example, the term you read was f(data).
That is, it is a compound term with principal function symbol 'f'
and arity 1, whose single argument is the atom 'data'.
So in the example that works, you are doing call(f(data)).
The library predicate prompted_line/2 reads a list of character
codes. In this particular example, the list was "f data".
The built-in predicate atom_chars(Atom, Chars) expresses the
relation between an ***ATOM*** and the list of characters
comprising the name of the atom. In this particular example,
the atom you got back was 'f data'.
So in the example that doesn't work, you are doing call('f data').
That is, you are trying to call a predicate whose predicate
symbol is 'f data' and which has no arguments. If you had said
"f(data)" instead of "f data", you would have ended up trying to
call a predicate of no arguments whose name was the atom 'f(data)'.
You should have got an error message which looked like this:
[Warning: The procedure 'f data'/0 is undefined]
(1) 1 Call: 'f data' ?
DO pay attention to the single quotes in the error message,
they ARE telling you something!
There are at least two ways of doing what you apparently want.
(a) prompt_and_read(Prompt, Term) :-
prompt(Prompt),
read(Term).
This version requires you to terminate the input term with a full
stop and layout character, as always when using read/1.
(b) :- ensure_loaded(library(charsio)).
prompted_term(Prompt, Term) :-
prompted_line(Prompt, Chars),
chars_to_term(Chars, Term).
This version doesn't require you to terminate the input with a
full stop and layout character, but it won't let you use more
than one line for the term either.
On the grounds of portability, efficiency, and general hygiene,
I'd go for (a).
------------------------------
Date: Thu, 31 Dec 87 9:52:44 PST
From: Kahn.pa@Xerox.COM
Subject: Concurrent Prolog Book Announcement
CONCURRENT PROLOG
COLLECTED PAPERS
(2 Vols.)
Edited by Ehud Shapiro
MIT Press Series in Logic Programming
ISBN 0-262-19266-7 (vol. 1) (pp. 560)
ISBN 0-262-19257-5 (vol. 2) (pp. 680)
ISBN 0-262-19255-1 (two volume set)
Table of Contents
Volume 1
The Authors ix
The Papers xv
Foreword xix
Preface xxi
Introduction xxv
Part I: Concurrent Logic Programming Languages 1
Introduction 2
1. A Relational Language for Parallel Programming 9
K. Clark and S. Gregory
2. A Subset of Concurrent Prolog and Its Interpreter 27
E. Shapiro
3. PARLOG: Parallel Programming in Logic 84
K. Clark and S. Gregory
4. Guarded Horn Clauses 140
K. Ueda
5. Concurrent Prolog: A Progress Report 157
E. Shapiro
6. Parallel Logic Programming Languages 188
A. Takeuchi and K. Furukawa
Part II: Programming Parallel Algorithms 203
Introduction 204
7. Systolic Programming: A Paradigm of Parallel Processing 207
E. Shapiro
8. Notes on the Complexity of Systolic Programs 243
S. Taylor, L. Hellerstein, S. Safra and E. Shapiro
9. Implementing Parallel Algorithms in Concurrent Prolog: The
Maxflow Experience 258
L. Hellerstein and E. Shapiro
10. A Concurrent Prolog Based Region Finding Algorithm 291
L. Hellerstein
11. Distributed Programming in Concurrent Prolog 318
A. Shafrir and E. Shapiro
12. Image Processing with Concurrent Prolog 339
S. Edelman and E. Shapiro
13. A Test for the Adequacy of a Language for an Architecture 370
E. Shapiro
Part III: Streams and Channels 389
Introduction 390
14. Fair, Biased, and Self-Balancing Merge Operators: Their
Specification and Implementation in Concurrent Prolog 392
E. Shapiro and C. Mierowsky
15. Multiway Merge with Constant Delay in Concurrent Prolog 414
E. Shapiro and S. Safra
16. Merging Many Streams Efficiently: The Importance of Atomic
Commitment 421
V.A. Saraswat
17. Channels: A Generalization of Streams 446
E.D. Tribble, M.S. Miller, K. Kahn, D.G. Bobrow, C. Abbott and
E. Shapiro
18. Bounded Buffer Communication in Concurrent Prolog 464
A. Takeuchi and K. Furukawa
References 477
Index 507
Volume 2
The Authors ix
The Papers xiii
Preface to Volume 2 xvii
Part IV: Systems Programming 1
Introduction 2
19. Systems Programming in Concurrent Prolog 6
E. Shapiro
20. Computation Control and Protection in the Logix System 28
M. Hirsch, W. Silverman and E. Shapiro
21. The Logix System User Manual, Version 1.21 46
W. Silverman, M. Hirsch, A. Houri and E. Shapiro
22. A Layered Method for Process and Code Mapping 78
S. Taylor, E. Av-Ron and E. Shapiro
23. An Architecture of a Distributed Window System and its FCP
Implementation 101
D. Katzenellenbogen, S. Cohen and E. Shapiro
24. Logical Secrets 140
M.S. Miller, D.G. Bobrow, E.D. Tribble and J. Levy
Part V: Program Analysis and Transformation 163
Introduction 164
25. Meta Interpreters for Real 166
S. Safra and E. Shapiro
26. Algorithmic Debugging of GHC Programs and Its Implementation
in GHC 180
A. Takeuchi
27. Representation and Enumeration of Flat Concurrent Prolog
Computations 197
Y. Lichtenstein, M. Codish and E. Shapiro
28. A Type System for Logic Programs 211
E. Yardeni and E. Shapiro
Part VI: Embedded Languages 245
Introduction 246
29. Object Oriented Programming in Concurrent Prolog 251
E. Shapiro and A. Takeuchi
30. Vulcan: Logical Concurrent Objects 274
K. Kahn, E.D. Tribble, M.S. Miller and D.G. Bobrow
31. PRESSing for Parallelism: A Prolog Program Made Concurrent 304
L. Sterling and M. Codish
32. Compiling Or-Parallelism into And-Parallelism 351
M. Codish and E. Shapiro
33. Translation of Safe GHC and Safe Concurrent Prolog to FCP 383
J. Levy and E. Shapiro
34. Or-Parallel Prolog in Flat Concurrent Prolog 415
E. Shapiro
35. CFL --- A Concurrent Functional Language Embedded in a Concurrent
Logic Programming Environment 442
J. Levy and E. Shapiro
36. Hardware Description and Simulation Using Concurrent Prolog 470
D. Weinbaum and E. Shapiro
Part VII: Implementations 491
Introduction 492
37. A Sequential Implementation of Concurrent Prolog Based on the
Shallow Binding Scheme 496
T. Miyazaki, A. Takeuchi and T. Chikayama
38. A Sequential Abstract Machine for Flat Concurrent Prolog 513
A. Houri and E. Shapiro
39. A Parallel Implementation of Flat Concurrent Prolog 575
S. Taylor, S. Safra and E. Shapiro
References 605
Index 635
------------------------------
End of PROLOG Digest
********************
∂04-Jan-88 0156 @Score.Stanford.EDU:coraki!pratt@Sun.COM 1987 Summary/1988 Prospectus
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 01:56:06 PST
Received: from Sun.COM by SCORE.STANFORD.EDU with TCP; Mon 4 Jan 88 01:45:46-PST
Received: from sun.Sun.COM ([129.144.1.3]) by Sun.COM (4.0/SMI-3.2)
id AA25499; Sat, 2 Jan 88 23:26:49 PST
Received: from coraki.UUCP by sun.Sun.COM (4.0/SMI-4.0)
id AA11289; Sat, 2 Jan 88 23:26:39 PST
Received: by coraki.uucp (4.0/SMI-1.2)
id AA00561; Sat, 2 Jan 88 23:23:52 PST
Date: Sat, 2 Jan 88 23:23:52 PST
From: coraki!pratt@Sun.COM (Vaughan Pratt)
Message-Id: <8801030723.AA00561@coraki.uucp>
To: csd-list@score.stanford.edu
Subject: 1987 Summary/1988 Prospectus
I'm always impressed when someone's prediction is fulfilled.
I'm doubly impressed when it's fulfilled by the predictor.
I'm triply impressed when the prediction is a substantial accomplishment.
I lose count when it's a long list of substantial accomplishments.
Looking forward to losing count again in 1989.
-v
∂04-Jan-88 0755 @Score.Stanford.EDU:FEIGENBAUM@SUMEX-AIM.Stanford.EDU supercomputing/politics
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 07:55:25 PST
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 4 Jan 88 07:52:19-PST
Date: Mon, 4 Jan 88 07:52:59 PST
From: Edward Feigenbaum <FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
Subject: supercomputing/politics
To: faculty@SCORE.Stanford.EDU
Message-ID: <12363933102.23.FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
McCarthy is right to sound the alarm. And Cheriton has captured accurately
the politics of the situation. (Those pesky physicists remain so
powerful on the Washington scene. Why?)....ed
-------
∂04-Jan-88 1010 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu supercomputing/politics
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 10:10:42 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 4 Jan 88 10:03:32-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA07324; Mon, 4 Jan 88 10:04:16 PST
Date: Mon, 4 Jan 88 10:04:16 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8801041804.AA07324@Tenaya.stanford.edu>
To: FEIGENBAUM@SUMEX-AIM.stanford.edu
Cc: faculty@SCORE.stanford.edu
In-Reply-To: Edward Feigenbaum's message of Mon, 4 Jan 88 07:52:59 PST <12363933102.23.FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
Subject: supercomputing/politics
I agree completely with JMC/Cheriton/Feigenbaum about the supercomputing
issue. I attended a FCCSET meeting in Washington (a committee consisting
of computer science federal funding agencies) to talk about Planning
Research in AI---but while there I listened to them report on progress
on a "National Initiative for High-Performance Computing" (read networking
and supercomputers). I complained both to Saul and to Bob Simpson that I
hoped this didn't substitute for supporting computer science. I'm
afraid we are really being out-manuevered by the physicists. Can the
NRC committee that Ed belongs to help out here? -Nils
∂04-Jan-88 1017 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Tuesday, Jan. 5
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 10:17:36 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 4 Jan 88 10:09:27-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA07353; Mon, 4 Jan 88 10:10:25 PST
Date: Mon, 4 Jan 88 10:10:25 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8801041810.AA07353@Tenaya.stanford.edu>
To: ac@score
Subject: Tuesday, Jan. 5
Tomorrow, Tues Jan 5, we have several important faculty events. Our
faculty lunch will feature a discussion on the topic of "relations
between the CS Dept. and other related departments and programs." I
know both David Cheriton and Jeff Ullman have an interest in raising
some issues. Probably the following items will be surfaced:
interdepartmental programs that CSD is involved in (MIS, SCCM, CSLI,
Symbolic Systems, etc.); consulting professorships; courtesy appointments.
Do come and join us.
We have three separate faculty meetings: general, tenured, and
full professors. (The latter two meetings will be considering
some promotion cases.) I'm afraid that we'll all have to plan on devoting
the whole afternoon (maybe more) to these meetings, but if we can get
everything done in one day it will avoid having to schedule other meetings
to finish up.
-Nils
∂04-Jan-88 1022 @Score.Stanford.EDU:coraki!pratt@Sun.COM Supercomputing considered harmless and sexy
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 10:22:51 PST
Received: from Sun.COM by SCORE.STANFORD.EDU with TCP; Mon 4 Jan 88 10:19:39-PST
Received: from sun.Sun.COM ([129.144.1.3]) by Sun.COM (4.0/SMI-3.2)
id AA04905; Mon, 4 Jan 88 10:21:21 PST
Received: from coraki.UUCP by sun.Sun.COM (4.0/SMI-4.0)
id AA07545; Mon, 4 Jan 88 10:22:40 PST
Received: by coraki.uucp (4.0/SMI-1.2)
id AA00798; Mon, 4 Jan 88 10:21:01 PST
Date: Mon, 4 Jan 88 10:21:01 PST
From: coraki!pratt@Sun.COM (Vaughan Pratt)
Message-Id: <8801041821.AA00798@coraki.uucp>
To: faculty@score.stanford.edu
Subject: Supercomputing considered harmless and sexy
Cc: coraki!pratt@Sun.COM
(Disclaimer: I am a Sun stockholder.)
I'd like to disagree with David Cheriton's message headed
"Supercomputers considered harmful." This isn't true at all.
Supercomputers are harmless. Not to mention sexy.
I recently represented Sun at a conference in Minneapolis which
celebrated the acquisition by a group of math heavies (including Bill
Thurston, the 1983 Fields medal winner, and Harvard's David Mumford) of
200 hours of supercomputer time (for the coming year) donated courtesy
of Cray and the Minnesota Supercomputing Center/Institute, along with a
bunch of Suns donated by Sun. 200 hours of Cray time is the equivalent
in cycles (not sure what the conversion is for floating point
operations) of roughly half a year of Sun-4 time or one year of Sun-3
time. Thus measured by cycles the Sun donation was at least as
substantial as the Cray/MSC donation. Ironically, of the substantial
newspaper publicity surrounding the event the supercomputing aspect
received the lion's share.
You can spend $10K on a Honda Accura, or you can use it to rent a
chauffered Rolls-Royce for appropriate occasions. There are definite
advantages to both. Not only are Rolls-Royces harmless (as long as
you don't stand in their way), they are much sexier than an Accura.
Were I not married I would rent Rolls-Royces up to the limit of my
budget.
-v
∂04-Jan-88 1034 @Score.Stanford.EDU:coraki!pratt@Sun.COM On royalties and Royalty
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 10:33:56 PST
Received: from Sun.COM by SCORE.STANFORD.EDU with TCP; Mon 4 Jan 88 10:23:41-PST
Received: from sun.Sun.COM ([129.144.1.3]) by Sun.COM (4.0/SMI-3.2)
id AA02258; Mon, 4 Jan 88 09:19:03 PST
Received: from coraki.UUCP by sun.Sun.COM (4.0/SMI-4.0)
id AA06095; Mon, 4 Jan 88 09:18:54 PST
Received: by coraki.uucp (4.0/SMI-1.2)
id AA00714; Mon, 4 Jan 88 09:17:30 PST
Date: Mon, 4 Jan 88 09:17:30 PST
From: coraki!pratt@Sun.COM (Vaughan Pratt)
Message-Id: <8801041717.AA00714@coraki.uucp>
To: ac@score.stanford.edu
Subject: On royalties and Royalty
Along the same lines, I suggest that next Halloween we go
trick-or-treating early so as to be sure of getting all the candy
before all those useless little kids take it all.
One of the incentives for a graduate student to graduate and get a job
as a professor is funding independence. Until then graduate students
are at the financial mercy of others in the department.
According to Nils we are not doing very well in providing support for
our first-year students. My take on this is that first-year students
are low priority items in the average research project and so in lean
years are the first to be cut out. For the department however they
should be as important as any other student.
If research advisors are reluctant to support first years the department
is put in the position of having to take up the slack. In the absence
of more direct support from research projects it would seem both
reasonable and proper for the department to obtain such support by
taking back what was originally its, namely its 1/3 of royalties.
Research projects should get their funding from the usual agencies and
not cannibalize their own department's very limited funds.
See you all at 5 pm next Halloween?
-v
∂04-Jan-88 1243 @Score.Stanford.EDU:cheriton@pescadero.stanford.edu.stanford.edu Re: Supercomputing considered harmless and sexy
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 12:43:27 PST
Received: from Pescadero by SCORE.STANFORD.EDU with TCP; Mon 4 Jan 88 12:40:39-PST
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA01554; Mon, 4 Jan 88 12:41:11 PST
Date: Mon, 4 Jan 88 12:41:11 PST
From: cheriton@pescadero.stanford.edu.stanford.edu (David Cheriton)
Message-Id: <8801042041.AA01554@Pescadero>
To: coraki!pratt@Sun.COM, faculty@score.stanford.edu
Subject: Re: Supercomputing considered harmless and sexy
Perhaps Vaughan should remember that:
1) most of the technology exploited by SUN Microsystems since its
inception was developed under research programs whose funding
is now significantly threatened and limited by this diversion
of funds into buying Rolls Royces.
2) I believe that a significant number of the early orders that SUN
received were from these same research programs.
3) Even if SMI is going to do all their own research to allow them to
keep up with the Japanese and others, where are they going to hire
the researchers from if the US CS depts. become incompetent due to
underfunding.
How soon we forget the hand that fed us!
∂04-Jan-88 1306 ARK@sail.stanford.edu EDBT 88 Program
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 13:06:38 PST
Received: from Sail.Stanford.EDU by navajo.stanford.edu with TCP; Mon, 4 Jan 88 12:58:08 PST
Date: 04 Jan 88 1232 PST
From: Arthur Keller <ARK@sail.stanford.edu>
Subject: EDBT 88 Program
To: kbms-people@score.stanford.edu, nail@navajo.stanford.edu
Dear Colleague:
Please give to this Advance Program of the EDBT 88 Conference
the maximum distribution. Many thanks and wishes.
Stefano Ceri, Michele Missikoff, Joachim Schmidt
-------------------------------------------------------------------------
INTERNATIONAL CONFERENCE
EXTENDING DATABASE
TECHNOLOGY
March 14-18, 1988
Cini Foundation, Venice, Italy
Organized by: Sponsored by: In cooperation with:
IASI-CNR AFCET ACM
ISDRS-CNR AICA IEEE
INRIA BCS
Politecnico di Milano GI
Universitat Frankfurt ESPRIT
CRAI CNR of Italy
-------------------------------------------------------------------------
CONFERENCE ORGANIZATION
CONFERENCE CHAIRMAN
S. Ceri, Universita' di Modena, Italy
PROGRAM COMMITTEE
Program Committee Chairperson:
J. W. Schmidt, J. W. Goethe Universitat, Frankfurt, FR Germany
Members:
S. Alagic (Yugoslavia), A. Albano (Italy), P. Apers(Netherlands),
M. Atkinson (Great Britain), F. Bancilhon (France), R. Bayer (FR
Germany), G. Beeri (Israel), G. Bracchi (Italy), M. Brodie (USA),
J. Bubenko (Sweden), S. Ceri (Italy), Q.Chen (China), P. Dadam
(F.R. Germany), R. Demolombe (France), D.J. De Witt (USA),
A.Furtado (Brasil), G. Gardarin (France), G. Gottlob (Austria),
L.A. Kalinichenko (USSR) , Y. Kambayashi (Japan), H. Kangassalo
(Finland), M. Missikoff (Italy), J. Mylopoulos (Canada), E.
Neuhold (F.R. Germany), J.M. Nicolas (F.R. Germany), A. Pirotte
(Belgium), A. Reuter (F.R. Germany), G. Schlageter (F.R. Germany)
A. Sernadas (Portugal), A. Solvberg (Norway), N. Spyratos
(France), P. Stocker (G. Britain), K. Subieta (Poland), P.
Thalheim (D.R. Germany), D.C. Tsichritzis (Switzerland) , Y.
Vassiliou (Greece), G. Wiederhold (USA), H. Williams (G. Britain)
C. Zaniolo (USA), C.A. Zehnder (Switzerland).
ORGANIZING COMMITTEE
Chairman:
M. Missikoff, IASI-CNR, Italy
Treasurer:
P. Atzeni, IASI-CNR, Italy
Industrial exhibitions coordinator:
A. D'Atri, Universita' de L' Aquila, Italy
Tutorial coordinator:
F. L. Ricci, IRSDS-CNR, Italy
EEC coordinator:
J. Elmore, Esprit Programme
US coordinator:
C. Zaniolo, MCC, USA
Members:
S. Ceri (Italy), H. Eckhardt (FR Germany), G. Gardarin
(France), K.G. Jeffrey (Great Britain), J.W. Schmidt (FR Germany),
G. Turco (Italy).
-------------------------------------------------------------------------
SESSIONS AND TIMETABLE
9.00-10.30 11.00-12.30 14.00-15.30 16.00-17.30
Monday Tutorial 1 (Gallaire)
March 14 Tutorial 2 (Nestor)
Tuesday Tutorial 3 (Batini-Reiner) Tutorial 5 (Bancilhon)
March 15 Tutorial 4 (DeWitt) Tutorial 6 (Bernstein)
-------------------------------------------------------------------------
Wednesday Opening Session 2 Session 3 Session 4
March 16 session Databases and Expert System Distributed
Logic Approaches to Databases and
Databases Transactions
Management
Thursday Session 5 Session 6 Project Session Project Session
March 17 Database Complex 7a: Support for 8a: Distributed
Administration Database Data and Database
Objects Knowledge-Based Applications
Applications
--------------------------------
Session 7b Session 8b
Efficient Data Efficient Data
Access 1 Access 2
Friday Session 9 Session 10 Panel Session 11 Session 12
March 18 Efficiency by Data Types Databases and Special Data
Replicated and Data Programing
Data Semantics Languages:
(inv. speaker: a Shut-Gun
L. Cardelli) Marriage
A TECHNICAL EXHIBITION will be open from Monday 14th to Friday 18th.
-------------------------------------------------------------------------
SOCIAL PROGRAM
Welcome Reception (Wednesday, March 16, 19:00).
Light Dinner and Baroque Concert (Thursday, March 17, 19:00).
Wine on the Laguna (Friday, March 18, 20:30).
-------------------------------------------------------------------------
TUTORIALS
Monday, March 14, 14.00 - 17.30
Tutorial N. 1: Logic and Databases
H. Gallaire, ECRC, FR Germany.
Tutorial N. 2: Database Technology for Software Engineering
J. Nestor, Carnegie Mellon University, USA.
Tuesday, March 15, 9.00 - 12.30
Tutorial N. 3: Database Design: Methodologies and Automated Tools
C. Batini, Universita' di Roma "La Sapienza", Italy.
D. Reiner, Lotus Development Corporation, USA.
Tutorial N. 4: Extensible Database Systems
D. J. De Witt, University of Wisconsin, USA.
Tuesday, March 15, 14.00 - 18.00
Tutorial N. 5: Object-Oriented Databases
F. Bancilhon, IN2, France.
Tutorial N. 6: Transaction Processing Systems
P. Bernstein, Digital Corporation, USA.
Detailed information about the Tutorials' content can be obtained
from:
F. L. Ricci
Tutorial coordinator
IRSDS - CNR
Via C. De Lollis 12
00185 Rome, Italy
ph. (39-6) 495-2351
-------------------------------------------------------------------------
REGISTRATION
Registration fee is in Italian lira; for participants'
convenience we add in parentesis the approximate prices in dollar
at the exchange rates of Lit. 1250 for 1 US $ (as of December
1987). Reduced fees apply to affiliates of: AICA, GI, BCS, AFCET,
ACM, IEEE.
Conference fee: before Febr. 15
full: Lit. 430.000 (US $ 350)
reduced: Lit. 360.000 (US $ 290)
after Febr. 15
full: Lit. 570.000 (US $ 455)
reduced: Lit. 485.000 (US $ 390)
Conference registration fee includes: the Conference Proceedings,
access to the Conference Exhibition, three lunches offered at the
Conference location on S. Giorgio Island, the participation to
the Welcome Reception and to the Wine on the Laguna events, and
the coffee breaks. The Light Dinner and Baroque Concert on
Thursday night require a separate ticket of Lit. 30.000 (US $
24).
Fee for the participation to one tutorial:
before Febr. 15
full: Lit. 200.000 (US $ 160)
reduced: Lit. 170.000 (US $ 135)
after Febr. 15
full: Lit. 240.000 (US $ 190)
reduced: Lit. 200.000 (US $ 160)
Tutorial registration fee includes the technical material and a
coffee break. On Tuesday 15th a restaurant service will be
available on-site (lunch ticket: Lit. 30.000).
-------------------------------------------------------------------------
HOW TO REGISTER
Advance registrations should be made by filling the registration
form and mailing it before February 15 to:
EDBT 88
IASI
Viale Manzoni 30
00185 ROMA - ITALY
Payments should be made with an international draft payable to:
CERIAS-EDBT or, alternatively, with an international money order
to:
CERIAS-EDBT
bank account 4585
c/o Banca Popolare di Bergamo
Agenzia Citta' Alta
24100 Bergamo, Italy
In case of international money order, please enclose a copy of
the money order with the registration form.
ON-SITE REGISTRATION will be accepted with international drafts
or cash at the Conference desk. The Conference desk will be open
from Monday 14 to Friday 18, from 8:30 am to 5:30 pm.
-------------------------------------------------------------------------
ACCOMMODATION
Accommodation for conference participants is available in four
hotel categories (see Hotel Reservation Form). Hotel Reservation
Form should be mailed to:
American Express CO SpA
BMC ITALY
Piazza di Spagna, 38
00187 Roma (Italy)
-------------------------------------------------------------------------
CONTACT ADDRESS
More information and a full printed copy of the Program can be
obtained from:
Michele Missikoff Carlo Zaniolo
IASI-CNR MCC
Viale Manzoni 30 3500 West Balcones Center Drive
00185 Roma Austin, TX 78759-6509
Italy USA
ph. (39-6) 770031 ph. (512)-343-0978
e-mail: Missikoff@iasi.cnr.osiride.ean
-------------------------------------------------------------------------
REGISTRATION FORM
NAME.................................
First Name...........................
Affiliation..........................
Address.............................. City....................
Country.............................. Post Code...............
Tel. ................................ Telex...................
Registration fees
Amount
Conference: before Febr. 15
full: Lit. 430.000 .......
reduced: Lit. 360.000 .......
after Febr. 15
full: Lit. 570.000 .......
reduced: Lit. 485.000 .......
Tutorials: fee for one tutorial
before Febr. 15
full: Lit. 200.000 .......
reduced: Lit. 170.000 .......
after Febr. 15
full: Lit. 240.000 .......
reduced: Lit. 200.000 .......
Please mark the tutorial(s) you wish to register for:
Tutorial 1 [] Tutorial 3 [] Tutorial 5 []
Tutorial 2 [] Tutorial 4 [] Tutorial 6 []
Baroque Concert with Dinner: Lit. 30.000 .......
TOTAL .......
PAYMENT
[] I enclose an international draft for the amount
indicated in the total.
[] I enclose the photocopy of the money order to
CERIAS-EDBT, bank account #4585, Banca Popolare di Bergamo
Agenzia Citta' Alta, 24100 Bergamo, Italy.
-------------------------------------------------------------------------
HOTEL RESERVATION FORM
Last Name............................
First Name...........................
Address.............................. City....................
Country.............................. Post Code...............
Tel. ................................ Telex...................
Name(s) of accompaning person(s):.............................
HOTEL ACCOMODATION: HOTEL CATEGORY: o Superior First Class
Nr .... Single Rooms o First Class
Nr .... Double Rooms o Second Class
From ........... To ........... o Economy
HOTEL RATES:
Superior First double room: Lit. 230.000
single room: Lit. 140.000
First class double room: Lit. 140.000
single room: Lit. 90.000
Second class double room: Lit. 110.000
single room: Lit. 70.000
Economy double room: Lit. 90.000
single room: Lit. 50.000
The above are daily rates, including breakfast and taxes. Enclose
payment for the first night + Lit. 10.000 as agent fee. Please
make your payment using:
o International Draft Nr..................................
o Personal Cheque Nr......................................
o American Express Card Nr. .......................
Expiration Date .................
Date .............. Signature ..........................
≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠≠
∂04-Jan-88 1342 @Score.Stanford.EDU:jlh@vsop.stanford.edu Re: supercomputing/politics
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 13:42:29 PST
Received: from vsop.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 4 Jan 88 13:39:33-PST
Received: by vsop.stanford.edu; Mon, 4 Jan 88 12:42:38 PST
Date: 4 Jan 1988 1242-PST (Monday)
From: John Hennessy <jlh@vsop.stanford.edu>
To: faculty@score.stanford.edu
Subject: Re: supercomputing/politics
In-Reply-To: nilsson@tenaya.stanford.edu (Nils Nilsson) /
Mon, 4 Jan 88 10:04:16 PST.
<8801041804.AA07324@Tenaya.stanford.edu>
What I have heard about and read about the National Initiative, which
Nils mentioned, indicates that it is not more money for
"supercomputing" in the sense of buying Crays for physicists. The
initiative focuses on research in large scale parallel machines
(DARPA's so called TeraOp project, which includes both hardware and
software) and in high speed networking - the money is for both research
and construction of machines and networks. The initiative also includes
some funding for basic computer science. What is different is that
scientific computing and the needs of that community are an explicit
component of the project (unlike the Stragetic Computing Initiative).
John
∂04-Jan-88 1401 RICHARDSON@Score.Stanford.EDU hello
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 14:01:22 PST
Date: Mon 4 Jan 88 13:45:15-PST
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: hello
To: faculty@Score.Stanford.EDU, students@Score.Stanford.EDU
Message-ID: <12363997231.36.RICHARDSON@Score.Stanford.EDU>
Hi! My name is Heidi Schubert and I will be working as a
temporary replacement for Anne Richardson for a few weeks. Please
feel free to contact me at 725-1430 if you need anything.
-------
∂04-Jan-88 1520 RICHARDSON@Score.Stanford.EDU summer research program
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 15:19:54 PST
Date: Mon 4 Jan 88 15:08:57-PST
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: summer research program
To: faculty@Score.Stanford.EDU, students@Score.Stanford.EDU
Message-ID: <12364012466.36.RICHARDSON@Score.Stanford.EDU>
This is to announce that there is a Summer Research Program for faculty
and graduate students with the United States Air Force Office of
Scientific Research. Please see Heidi in Room 214 to view the
information booklet.
-------
∂04-Jan-88 1759 LOGMTC-request Logic seminar, correction
Received: from RUSSELL.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 17:59:01 PST
Received: by russell.stanford.edu (3.2/4.7); Mon, 4 Jan 88 18:02:13 PST
Date: Mon 4 Jan 88 18:02:12-PST
From: Sol Feferman <SF@Russell.Stanford.EDU>
Subject: Logic seminar, correction
To: logmtc@SAIL.STANFORD.EDU
Message-Id: <568346532.0.SF@Russell.Stanford.EDU>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@Russell.Stanford.EDU>
The ;meeting λλλλλλλλλλλλλ
The meeting room for Longo's talk, Tues. Jan.5, 4:15-5:30, will be in
room λλλλλλ381T, Math Bldg. 9λ(first floor).
S. Feferman
-------
∂04-Jan-88 2357 @Score.Stanford.EDU:coraki!pratt@Sun.COM Supercomputing considered harmless and sexy
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 23:57:48 PST
Received: from Sun.COM by SCORE.STANFORD.EDU with TCP; Mon 4 Jan 88 23:55:56-PST
Received: from sun.Sun.COM ([129.144.1.3]) by Sun.COM (4.0/SMI-3.2)
id AA01025; Mon, 4 Jan 88 23:57:43 PST
Received: from coraki.UUCP by sun.Sun.COM (4.0/SMI-4.0)
id AA15089; Mon, 4 Jan 88 23:59:05 PST
Received: by coraki.uucp (4.0/SMI-1.2)
id AA01104; Mon, 4 Jan 88 23:41:53 PST
Date: Mon, 4 Jan 88 23:41:53 PST
From: coraki!pratt@Sun.COM (Vaughan Pratt)
Message-Id: <8801050741.AA01104@coraki.uucp>
To: faculty@score.stanford.edu
Subject: Supercomputing considered harmless and sexy
Cc: coraki!pratt@Sun.COM
Perhaps Vaughan should remember that:
1)...2)...3)...
How soon we forget the hand that fed us!
Sun has not been particularly vocal about advertising either its
products or its support of academic projects at a wide range of
universities. However neither are insignificant. In the latter
category, according to Sun's Emil Sarpa, Stanford for example has
received approximately $400,000 in equipment grants from Sun in recent
years. I'm not sure what the average size of Sun was in that period,
but if we say it was 1% of IBM then that would correspond to a $40M
equipment grant from IBM. Those of you familiar with DEC can figure
out the corresponding DEC number.
In view of the circumstances surrounding Sun's beginnings I am inclined
to regard these donations less as rewarding the hand that fed Sun than
as addressing David's point (3) about the need for industry to support
universities for the future. Looking over my 1980-81 correspondence I
note a lot of mail concerning lack of support for the Sun project by
various Stanford people, along with some outright opposition to it. In
the eighteen months of my association with the project at Stanford
there were exactly three outsiders who provided the project with
substantial support: Ralph Gorin, Jim Clark, and Don Knuth. Ralph
provided CSD-CF funds for parts until pressured to stop by faculty
protests about this being an inappropriate use of CSD-CF funds. Jim
provided a 140 Mbyte disk and Interphase controller from VLSI funds,
and also connected us up with CadLinc. And Don both made it possible
for me to spend my sabbatical at Stanford and was very encouraging
about the Sun project. In addition, in 1981 David Cheriton and Keith
Lantz became enthusiastic about the possibilities for Suns at Stanford,
thereby providing valuable moral support. Besides that, the principal
attitudes towards the project ranged from misunderstanding of the
objectives to outright antagonism.
It is accurate if not gracious to say that the "hand that fed us" mainly
spanked us.
My apologies to anyone I've overlooked or slighted unfairly.
-v
∂05-Jan-88 0158 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V6 #3
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 88 01:58:33 PST
Date: Mon 4 Jan 1988 09:23-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V6 #3
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Tuesday, 5 Jan 1988 Volume 6 : Issue 3
Today's Topics:
Query - Variable Order,
Implementation - Task Analysis,
LP Library - Computing with Logic
----------------------------------------------------------------------
Date: Fri, 01 Jan 88 00:29:10 EST
From: Michael Covington <MCOVINGT%UGA.BITNET@forsythe.stanford.edu>
Subject: Dependency Grammar / Variable Word Order
I would like to hear of any work, published or unpublished, on the
following topics:
(1) Parsing using a dependency rather than a constituency grammar,
i.e., by establishing grammatical relations between individual words
rather than gathering words into groups.
(2) Parsing strategies that have been used successfully with languages
that have variable word order, such as Russian or Latin.
I am familiar with GPSG, HPSG, and ID/LP grammars, and with various
proofs that (some) dependency grammars are equivalent to (some) con-
stituency or phrase-structure grammars. However, there must have been
some good ideas in circulation much earlier, perhaps in connection
with early machine translation work.
------------------------------
Date: Sat, 2 Jan 88 01:52:07 PST
From: quintus!ok@Sun.COM (Richard A. O'Keefe)
Subject: Task analysis
Has anyone done a task analysis for Prolog?
I'm picking the brains of someone who was incautious enough to let
his e-mail address appear in a message sent to comp.edu. Amongst
other things, he wrote
I carried this further in my introductory courses, producing an
enumerated Basic Skill Set that explained what each student was
expected to attain. If, at any time, the student felt he/she
didn't have any of the basic skills in any part of the course,
it was up to them to come and get assistance. We had found that
students new to computing didn't have any firm idea of the level
of detailed knowledge expected of them --- and didn't know how
to find out. We ended up with a "contract" document that
contained all that and the student performance JUMPED! I've
seen a few texts that use this idea, too.
Rudolf Flesch, in "Why Johnny STILL Can't Read" has some similar remarks
about the value of a Task Analysis.
The generally excruciatingly bad level of Prolog textbooks strongly
suggests that the people who wrote them didn't have an explicit task
analysis written down. I've just started trying to sketch one out,
and it looks like a lot of hard work. Of course, I have never done
a task analysis of anything before, which doesn't help. Frankly, I'd
like references to task analyses for ANY programming language, or even
for word processing.
For the benefit of people who don't know what task analysis is all about,
the idea is that you work out what it is you want your students to be
able to do by the end of the course. Then you ask yourself, ok, what
sub-tasks and skills does that require? And so on recursively. The
point is to break up the rather amorphous topic "understanding Prolog"
or whatever into a partially ordered set of subskills. And not just any
subskills: you want the small chunks to be such that you can test
whether or not a student understands each particular chunk.
For the sake of concreteness, I am starting with a single program
fragment.
/* We are given a tree defined by two predicates:
start(Start) is the root of the tree
children(Node, Children) relates a node to a list of its children.
We want to find nodes which satisfy a third given predicate:
solution(Node) is true of the nodes wanted and no others
*/
% breadth_first(Answer)
% is true if Answer is a node in the tree defined by start/1 and
% children/2 and satisfies solution/1. The searching method used
% is simple breadth-first search. That is, all the nodes at any
% level of the tree will be checked before any of their children.
breadth_first(Answer) :-
start(Start),
breadth_star([Start], Answer),
solution(Answer).
breadth_star([OpenNode|OpenNodes], Node) :-
( Node = OpenNode
; children(Node, Children),
append(OpenNodes, Children, OpenNodes1),
breadth_star(OpenNodes1, Node)
).
The point is, what do you have to know to understand this?
(1) English.
It is important to be able to read English comfortably.
It is not enough to recognise a few thousand words by sight and
guess at the rest. You have to be able to SEE the letters and
punctuation marks and appreciate that spelling and punctuation
matter. You also have to have some glimmerings of discourse
structure. (E.g. the ordering background-comment, predicate-
comment, top-level predicate, loop predicate is very far from
being arbitrary!)
Of course I could have written this using French comments and
French identifiers, and then the first thing to understand would
have been French. The specific language doesn't matter. But
familiarity with an alphabetic writing system is important.
The idea that words have structure is also important here.
There are at least three regular morphological processes going
on in the variable names here:
OpenNode has the form <Adjective><Type>
OpenNodes has the form <NounPhrase>+plural
OpenNodes1 has the form <SequencePhrase>+ordinal
You have to be able to SEE this kind of thing.
{Digression: in a Prolog system which supports Kanji, the convention
would presumably be to affix kanji signifying "sequence" or whatever
and ordinal position, so this same pattern would be seen as phrase
structure within variable names rather than morphological structure.
Anyone care to comment?}
Anyrate, basic reading skills are needed here for three things:
- the accompanying text
- the comments
- the Prolog code itself
One of the teacher's tasks is to help the students transfer their
existing reading skills to Prolog. This means that we have to
make explicit
- character set
- lexical structure
- morphological rules
- discourse rules
(2) Trees.
I have long been of the opinion that high-school children should
be explicitly taught "trees". Trees show up all over the place;
game trees, decision trees, phylogenetic trees, organisational
charts. I cannot think of any high-school subject I took where
trees didn't appear. (That specifically includes PhysEd.) Why
not spend a couple of periods being explicit about them? It'd
take a lot of the mystery out of algebra.
Trees are needed two ways in this example.
The *problem* is about searching trees. The idea of a generator
(in the mathematical sense) is important here too: we are not
given the tree to be searched as an explicit data structure, but
as a base (start/1) and generator (children/2). In fact a really
important skill you need for this kind of problem is to be able
to shift between different representations of a tree and still
understand that the same thing is going on. (For example, we
might be given root(Start) and arc(Parent, Child) predicates
instead of start/1 and children/2, and it has to be clear that
nothing fundamental has changed.) Later examples in the set
this is drawn from attach heuristic estimates to children and
sort them in various ways. Again it has to be understood that
this doesn't change what the tree IS, only how we look at it.
Prolog data structures are trees. In order to understand Prolog
data structures, you have to understand trees first. You have
to grasp the fact that fred(1,2) is isomorphic to a tree with
three nodes, and that 1 is isomorphic to a tree with one node,
and that it makes just as much sense to ask for the label on
the root of the tree 1 is isomorphic too (in other words, to
call functor(1, Label, Arity)) as it does to ask for the label
on the root of the tree fred(1,2) is isomorphic to (in other
words, to call functor(fred(1,2), Label, Arity)). Of course
buggy Prolog systems which get functor(1, F, N) wrong don't
exactly help here...
There is a third way in which trees are relevant, and it is the
one that most Prolog books stress. Namely, the execution tree.
The Open University have a tree representation which is easily
the best I have seen. BUT this tree is totally irrelevant to
the way I understand this fragment.
This is an important point. Keeping the wrong things out of a
Task Analysis is just as important as getting the right things in.
I cannot stress sufficiently that I do not find execution trees
helpful in thinking about Prolog. I have never in my life drawn
a Prolog execution tree of any sort for my own benefit. This
particular fragment started life as
start. .child.* .answer
(an algebraic view), hence the name breadth_star/2.
(3) Basic logic.
Relations, conjunction and disjunction.
(4) Lists and append.
An important distinction in this particular example is that between
sequences and sets. Exploiting this is the key to deriving better
searching methods. The full context includes depth first search
(swap the first two arguments of append/3) and it is important to
grasp that this changes the sequence in which the tree is searched
without changing the set of nodes which might be searched.
(5) Argument use.
There is a conventional order of arguments in Prolog.
If you don't know it (or if the programmer ignored it) you have a
hard time reading Prolog code. In this particular example, there
was no freedom of choice whatsoever with respect to argument order,
and it is important to understand why.
The trouble is, this is much too general, and there are gaping holes in
it even so. For example, I've known 1st order PC since high-school days;
I can no more remember what it was like not to be able to read predicate
calculus than I can remember what it was like not to be able to read music.
I'm really having trouble trying to see the gaps, and trying to work out
what the subskills are.
I should make it clear that the goal is to teach people how to read
WELL-written Prolog programs. I have seen some real shockers (even
one written by someone who used to be at Quintus, but isn't any more...),
and it isn't reasonable to expect ANYONE to be able read badly written
programs. I know there has been some work done with Pascal showing that
"expert" programmers were little better than novices at reading programs
that violated Pascal discourse conventions, and I believe the same is
true of Prolog.
So, does anyone have a Task Analysis for Prolog?
------------------------------
Date: Mon, 4 Jan 88 08:53:15 cst
From: overbeek@anl-mcs.ARPA (Overbeek)
Subject: Comments on "Computing with Logic" by Maier and Warren
Richard O'Keefe recently posted a review of
Computing with Logic: logic programming with Prolog
David Maier/David S. Warren
While I have the greatest respect for Richard O'Keefe, I believe
that many of his comments were inappropriate for two reasons:
1. The book actually is very, very good. It's main
strengths are pedagogical, and Richard simply
failed to understand or appreciate them.
2. Richard frequently exhibits a rather brutal style.
He obviously prefers this type of interchange, where
harsh statements do not carry the connotations that
they do in ordinary discourse (i.e., normally statements
of the sort that Richard makes mean not only "you have
made serious technical oversights", they also mean
"and I think you are an idiot"). There is no right
or wrong to setting the ground rules of intercourse.
However, it seems worth observing that Richard's tone
is inhibiting the exchanges that might occur. I certainly
would not open myself up to one of Richard's caustic,
public lashings under normal circumstances. This time,
I think that someone must respond. The book is simply
too good to allow a review like Richard's to go unanswered.
On the other hand, I am tempted to use a pseudonym.
Why do I consider the book a useful contribution to a growing
literature? A short response would be something like
If you wanted to train young researchers in the field of logic
programming, this book is one of the best starting points.
It offers a good initial introduction to the concepts of logic
programming, the formal theory supporting the use of logic
programming, and the implementation of logic programming.
In creating an introductory textbook, authors make a number of critical
decisions. Perhaps the most important involves a selection of material.
You must rank topics according to priority and make sure that the
most important get covered, while the less fundamental do not.
The authors of this text chose to start their exposition with
propositional logic, from the point of view of logic programming.
They successfully conveyed most of the fundamental ideas of logic
programming, much of the essential theory supporting its use
(resolution, interpretations, models, satifiability, etc.) in a highly
simplified context, and some insights into implementation. All of
this is done rather painlessly in the early chapters of this book.
It represents a marvelous pedagogical achievement, in my opinion.
Then, they move on to predicate calculus without functions. In this
simplified formalism, things like Herbrand's theorem can be made
easily accessible. (I can just hear Richard: "Don't pander to the
idiots; give it to them straight so we can separate the real
students from those that are wasting the taxpayers money!"). By
mixing informal discussions, the theory in graduated doses, and
a carefully motivated introduction to implementation, the book
successfully reduces the "intellectual cost" of acquiring the
background required to understand the more advanced issues.
Finally, the book goes on to cover the predicate calculus with
function symbols, Prolog, and some advanced topics in implementation.
Now, let me return to the point that an author must carefully select
material for an introductory text. Failure to leave out complex, but
less than fundamental topics, is just as damaging as failure to include
important topics. It is simply not wise to criticise such a text for
failing to cover garbage collection within the WAM; indeed, the authors
should be commended for restraining themselves. They include an
incredible amount of material, most of which is presented beautifully.
This single book includes an easily understood introduction to
logic programming, Herbrand's theorem, and an introduction to the WAM.
Figuring out how to pull that off required a great deal of effort and
work. The result deserves applause, not the flippant criticism
offered by O'Keefe.
-- Ross Overbeek
------------------------------
End of PROLOG Digest
********************
∂05-Jan-88 1418 FACIL-mailer Facilities Committee meeting
To: facil@SAIL.Stanford.EDU
CC: Nilsson@SCORE.Stanford.EDU
From: Les Earnest <LES@SAIL.Stanford.EDU>
A meeting of the Facilities Committee is scheduled for Wednesday, January 20
at 1:30pm in Jacks room 352. Here are some proposed topics. I invite
suggestions for additional topics; please send me a message if you have any.
1. Pricing policies on Polya and other systems. For example, should we
offer a restricted class of service (at lower rates) for people who just
need access to email and bboards? They could be barred from running
during prime time, could be limited on the amount of disk and CPU they
could use, and might be restricted to running only email and bboard programs.
2. Review of APS typesetter and B&H slidemaker services. Should they be
continued/finished?
3. Review of plans for the Ncube computer called Braque. Who should take
responsibility for running it? Should it run as a cost pool or a cost
center?
If anyone on the committee is interested, you are also invited to a
meeting next week among prospective users of Braque to discuss item 3
above. It will be at 1:30pm on Wednesday, January 13, also in Jacks 352.
Les Earnest
CS Facilities Committee Chair
∂06-Jan-88 0526 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V6 #4
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 88 05:26:07 PST
Date: Wed 6 Jan 1988 03:05-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V6 #4
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Wednesday, 6 Jan 1988 Volume 6 : Issue 4
Today's Topics:
Implementation - Strings,
Puzzle - Tick & Lampson & Caution,
LP Library - Update
----------------------------------------------------------------------
Date: 31 Dec 87 07:17:00 EST
From: <cugini@icst-ecf.arpa>
Subject: Prolog strings, etc.
I'm not sure if this is entirely responsive to O'Keefe's call for
plausible uses of strings, but it's somewhat related. I should say
first that I am less concerned with efficiency (although not
unconcerned) than O'Keefe appears to be, and more so with ease
of programming (what, no arccosh function ?).
Strings seem to me most useful when your application involves the
processinmg of text (surprise), and in particular when the length
of the text-chunks is important. For instance, if you want to
print out a table with columns left or right-justified or centered;
or if you want to format a paragraph, a la troff, runoff, with
standard-size lines, possibly right-flush. It seems to me that the
above functions are pretty complicated to achieve without knowing a
lot about the exact number of characters to be generated.
A particular problem is finding out the length, not just of atoms,
but of compound terms.
This brings up an old complaint of mine. Why, for crying out loud,
can't there be a Prolog function like this:
fullname(Term, String)
which, given any Term, esp. including *compound* terms, returns the
string of characters which would be generated upon writing that
Term (including, of course, the effect of current operators, etc.);
and conversely, given a string, constructs exactly the term which
'read' would have. Clearly this term:string conversion is
implemented, since it happens on I/O all the time. BTW this is
analogous to FORTRAN's pseudo-IO and to Lisp's format with a string
(rather than a file) as destination. I know there are quibbles over
whether this should simulate write or writeq or print, error
conditions, etc, but those can be worked out.
-- John Cugini
------------------------------
Date: Sat, 2 Jan 88 22:21:28 PST
From: quintus!ok@Sun.COM (Richard A. O'Keefe)
Subject: Benchmark caution.
Udi Shapiro recently sent the Prolog Digest an FCP version of the
"Puzzle" benchmark. My concern is not with that code, but with a
minor point about Evan Tick's original program.
Shapiro says "For comparison, Evan's Prolog program runs interpreted
under Quintus Prolog Version 1.0 on the Sun-3/50 for 55 seconds, and
compiled 12 seconds." Fortunately, he gives the original program,
so we can see what is going on. It turns out that almost all of the
time is overhead maintaining the counter.
The same program running compiled in Quintus Prolog version 2.0 on
a Sun-3/50, took
2.9 seconds, using library(ctr) to manage the counter
2.8 seconds, using stubs to do nothing to the counter
So of the 12 seconds quoted, roughly 9 seconds were spent managing the
counter, which Quintus Prolog *can* do in 0.1 seconds.
All I'm saying here is that if you are benchmarking, be careful that
you are measuring the program, not the measuring instruments!
[PS: I hope Typed FCP is described in "Concurrent Prolog: Collected
Papers". I ordered it from MIT Press, but haven't got it yet.]
------------------------------
Date: 12 Dec 87 01:47:10 GMT
From: thorin!unc!bts@mcnc.org (Bruce Smith)
Subject: updated list of Prolog implementations...
Well, it's time (past time, actually) for a new LIST-OF-PROLOGs. I'll
be posting it -- almost 1K lines -- in my next message. Here is a
quick summary.
New or updated entries:
BIM_Prolog, Blog, CLP(R), GProlog, Horne,
IF/Prolog, Lambda-Prolog, LISPLOG, LM-Prolog, MU-Prolog,
NU-Prolog, POPLOG, Prolog-CRISS, Rhet, Sicstus Prolog,
Trilogy, UNSW Prolog, WProlog
Unchanged since the last posting:
A.D.A. Prolog, Arity/Prolog, Basser Prolog, C-Prolog, IC Prolog,
ICL Prolog, The Logic Workbench, LOGLISP, MProlog, Modula-Prolog,
Pascal Prolog, Prolog-1, Prolog-2, Prolog-10 and Prolog-20,
Prolog-86, Prolog-II, Prolog-V, Prolog/P, Quintus Prolog, Salford
Prolog, UNH Prolog, UNIX Prolog, Uranus Prolog, VPI Prolog, York
Portable Prolog
I'd appreciate hearing from anyone who can tell me about the unchanged
entries. Are those systems still available? How have they changed?
Finally, I'd like to hear something from users (or implementors) of
of the following, along with any others I've missed.
C-Prolog+
Edinburgh Prolog (formerly NIP - New Implementation of Prolog)
Epilog
Parlog
PLM (Aquarius Project at Berkeley)
Wisdom Prolog
Virginia Tech compiler
Xenologic
-- Bruce T. Smith
------------------------------
End of PROLOG Digest
********************
∂06-Jan-88 1750 emma@russell.stanford.edu CSLI Monthly
Received: from RUSSELL.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 88 17:50:26 PST
Received: by russell.stanford.edu (3.2/4.7); Wed, 6 Jan 88 17:10:22 PST
Date: Wed, 6 Jan 88 17:10:22 PST
From: emma@russell.stanford.edu (Emma Pease)
To: friends@russell.stanford.edu
Subject: CSLI Monthly
January 1988
Dear Monthly Subscriber:
CSLI has decided to suspend publication of the Monthly, at least
temporarily. On request, I will send you a copy of our Fourth Year
Report, which contains the project reports that were promised for the
next few issues of the Monthly. Please send e-mail with your postal
address to hyde@russell.stanford.edu if you would like to receive a
copy of the report.
Attached is a report from Ivan Sag about the 1987 Linguistic
Institute, an announcement about CSLI's postdoctoral fellow program
for 1988-89, and a list of visiting scholars as of fall 1987.
Thank you for your interest in CSLI. I hope you will continue to keep
in contact with us via our CSLI reports and CSLI lecture notes. For
further information about these series, please write to:
Dikran Karagueuzian
Editor
Center for the Study of Language and Information
Ventura Hall
Stanford University
Stanford, CA 94305-4115
Sincerely,
Elizabeth Macken
Associate Director
CSLI
--------------------
THE 1987 LINGUISTIC INSTITUTE
>From 29 June to 7 August 1987, the Stanford Linguistics Department was
host to the 54th Linguistic Institute, whose theme was "Computational
and Contextual Dimensions of Language." The program we mounted
offered more than sixty courses in a number of different research
areas, including linguistic theory, computational linguistics,
discourse analysis, psycholinguistics, sociolinguistics, artificial
intelligence, historical linguistics, the philosophy of language,
educational linguistics, theories of information, and African
linguistics. These courses were taught by more than eighty faculty,
including many CSLI researchers, and attracted more than a thousand
participants. In addition, there were eight conferences, five ongoing
workshops, and three lecture series. It was exhausting, but it was
exhilarating.
Since the 1920s, the Linguistic Society of America (LSA) has sponsored
Linguistic Institutes on any number of university campuses. They have
always been the locus of intellectual excitement, featuring courses by
distinguished scholars from all over the world. And our Institute was
no exception. But ours was unique in a number of ways: it was
probably the biggest (counting all the diverse sorts of participants);
it was the most interdisciplinary (the faculty included a bevy of
computer scientists, psychologists, and philosophers); it was the most
"hi-tech" (hundreds of linguists took their first crack at
sophisticated computing facilities) and it was the most intense. I've
participated in nine previous Institutes, and never have I seen people
attend lectures virtually nonstop from early in the morning to late at
night and still have the energy to boogie 'til they dropped on
weekends.
What got these hundreds of people so excited? It wasn't just the
well-catered parties and the rock 'n' roll (was it?). It was the
enthusiasm of the individual instructors, the quality of the courses,
the richness of the special events, and -- in hundreds of cases -- the
opportunity to get a first-hand acquaintance with the work being done
around CSLI. Computational linguistics in particular seemed to be the
most popular area of study, but situation semantics, information-based
grammatical theories, and discourse/pragmatics also generated
enthusiastic responses from the large number of students, visiting
scholars, and other auditors who attended courses in these areas.
At the 1974 Institute at UMass (Amherst), there were two courses in
particular that generated this same sort of excitement: Barbara
Partee's Montague Grammar course, and David Perlmutter and Paul
Postal's course in relational grammar. In both cases, Institute
participants from all over the world took away new ideas,
perspectives, and analytic techniques, which gave rise to new research
communities in many distant lands. Both research traditions have had
a major impact on the field of linguistics, due in no small part to
the Amherst Institute. It will be interesting to watch the effects of
our Institute in the years to come.
But even if you missed it (while you were on vacation in the south of
France), all is not lost. Thanks to the efforts of Fernando Pereira,
Ray Perrault, and Bob Moore, SRI International agreed to finance the
videotaping of eleven Institute courses (those taught by Kay, Pereira,
Shieber, Pollard and Sag, Bresnan, Hayes and Nilsson, Gazdar and
Mellish, Chierchia, and Gazdar and Pullum). These will be available
for sale in the near future, with part of the royalties going to a
fund to support fellowships for future Linguistic Institutes.
There are many debts to acknowledge. The Institute received generous
support from its cosponsoring organizations, the Linguistic Society of
America, the Association for Computational Linguistics, and the
American Association for Artificial Intelligence, as well as from the
Sloan Foundation and the Soros Foundation. In addition, the System
Development Foundation made a generous gift to the LSA to support
student fellowships. Thanks are also due to the Xerox Corporation,
which contributed the services of several Institute faculty and
support for the Logic and Linguistics Conference; to the
Hewlett-Packard Company, which sponsored the symposium on Evaluating
Natural Language Systems and an elegant post-symposium reception; to
AT&T Bell Laboratories and Schlumberger Laboratories, each of which
contributed the services of a faculty member; and to the IREX Board of
ACLS, which supported the symposium on Lexical Semantics.
But in particular, I would like to take this opportunity to thank
CSLI, which (under the inspired leadership of Tom Wasow) provided
constant support for every aspect of the 1987 Linguistic Institute,
including our computer needs, our brochures, our posters, virtually
every conference and workshop, and most importantly, our students. It
would have been a very different Institute without the help of the
CSLI staff (thanks to Emma, Rich, Brad, Doug, and Joyce in
particular), and the various individuals supported by CSLI research
funds who graciously contributed their lecturing services.
It was an honor and a privilege to serve as director of the Institute,
an honor and a privilege I will gladly pass on to one of you, should
we ever decide (God help us!) to do it again.
Ivan A. Sag
Director: 1987 Linguistic Institute
(on sabbatical: 1987--1988)
--------------------
POSTDOCTORAL FELLOWSHIPS
The Center for the Study of Language and Information (CSLI) at
Stanford University is currently accepting applications for a small
number of one-year postdoctoral fellowships commencing 1 September
1988. The awards are intended for people who have received their
Ph.D. degrees since June 1985.
Postdoctoral fellows will participate in an integrated program of
basic research on situated language -- language as used by agents
situated in the world to exchange, store, and process information,
including both natural and computer languages.
Awards are intended for scholars interested in at least one of the
following areas of research: situation theory and situation semantics,
discourse as rational activity, and embedded computation.
For more information about CSLI's research programs and details of
postdoctoral fellowship appointments, write to:
Dr. Elizabeth Macken
Associate Director
Center for the Study of Language and Information
Ventura Hall
Stanford University
Stanford, CA 94305-4115
APPLICATION DEADLINE: 7 MARCH 1988
--------------------
CSLI VISITORS AS OF FALL QUARTER 1987
SYLVAIN BROMBERGER
Professor of Philosophy
Department of Linguistics and Philosophy
Massachusetts Institute of Technology
Dates of visit: September 1987 - July 1988
Bromberger is currently interested in the philosophy of linguistics
and in rational acquisition of knowledge. In the philosophy of
linguistics he is working on conceptual issues arising in
phonology/phonetics. Under rational acquisition of knowledge he is
interested in the limits that constrain search for knowledge guided by
questions and in the semantics of interrogatives. He is a regular
participant of the RATAG project.
KEITH DEVLIN
Reader in Mathematics
Department of Mathematics
University of Lancaster
Dates of visit: September 1987 - August 1988
Devlin is a mathematical logician. About three years ago, his
interest in set theory gave way (via a brief passage through computer
science) to a desire to work out a genuine, mathematical theory of
information. He thought that the approach to this problem adopted by
Barwise and his colleagues at CSLI was the best way to proceed,
and has subsequently thrown his lot in with this gang. He is
presently writing a book on situation theory.
CARL GINET
Chair, Sage School of Philosophy
Cornell University
Dates of visit: June - December 1987
Ginet is a philosopher on sabbatic leave from Cornell. During his
stay at CSLI, he will be finishing a book on action, catching up on
the literature in epistemology, and refining software he has written
that guides students in constructing derivations in formal logic.
KIYONG LEE
Department of English
Korea University
Dates of visit: December 1986 - December 1987
Lee is visiting CSLI on a senior research grant from the
Korean-American Educational Commission and the Council for
International Exchange of Scholars. He hopes to acquaint himself with
new developments in situation theory and semantics, and to write an
introductory book for Korean readers. While working on some
foundational aspects of situation theory, he is very much interested
in testing its adequacy in treating some concrete problems, especially
those related to negation, quantification, and tense/aspect in Korean.
He is participating in the STASS project while he is here and also
continues developing a computationally tractable, functor-driven,
phrase structure grammar of natural language by amalgamating a
categorial grammar with HPSG.
SALLY MCCONNELL-GINET
Professor
Department of Modern Languages
and Linguistics
Cornell University
Dates of visit: June - December 1987
During her time at CSLI (the first half of a year's sabbatic leave
from Cornell), McConnell-Ginet will be working on a book about formal
approaches to the analysis of vagueness. She will also be working on
a semantics text for linguistics that she and Gennaro Chierchia are
coauthoring.
HIDEYUKI NAKASHIMA
Senior Researcher
Man-Machine Systems Section
Electrotechnical Laboratory
Dates of visit: September 1987 - August 1988
Nakashima is interested in knowledge representation, reasoning, and
learning. He is also interested in a model of language acquisition.
He has his own knowledge-representation system based on logic
programming, called Uranus. He is planning to create a programming
language based on situation theory.
RONALD NASH
Dates of visit: January 1987 - July 1988
Nash is at CSLI on a postdoctoral fellowship from the Social Sciences
and Humanities Research Council of Canada. He is interested in the
philosophy of mind and normative psychology, and is particularly
interested in the work of CSLI's RATAG and DIA projects with respect
to the cognitive theory of emotion on which he has recently worked.
He hopes to construct a more formal model while he is here, and will
be looking at the various formal models being considered at CSLI.
KASPER OSTERBYE
Institute of Electronical Systems, Aalborg
University of Aarhus
Dates of visit: September 1986 - September 1987
Osterbye's recent work has been on programming languages, especially
dealing with interactive higher-level debugging. At CSLI, he is
participating in the SDL project.
GORDON PLOTKIN
Professor
Department of Computer Science
University of Edinburgh
Dates of visit: September 1987 - October 1988
Plotkin is interested generally in issues of language and logic and
particularly in the modeling and formalization of situation theory and
in learning situation semantics. He is also interested in a variety
of issues in the denotational semantics of programming languages, such
as concurrency and probabilistic computation, and also in a usefully
implementable general proof theory. He is an active participant in
the STASS project.
BILL ROUNDS
Associate Professor
Department of Computer Science
University of Michigan
Dates of visit: September 1987 - June 1988
Rounds is a computer scientist interested in mathematical and
computational linguistics. He is developing logics for expressing
grammars and for understanding grammatical properties, with special
emphasis on unification-based grammatical systems. These logics can
also be used directly in implementations of such systems. He is
participating in the MOST project at CSLI.
HIROYUKI SUZUKI
Researcher
Systems Tokyo Research Department
Corporate Engineering Division
Matsushita Electric Industrial Co., Ltd.
Dates of visit: September 1986 - March 1988
Suzuki's main interest lies in building Japanese dialog systems. He
is currently interested in designing a representation language for a
computer as a participant of conversations, and clarifying strategies
for generating sentences that are employed by human beings to keep
conversations coherent.
SYUN TUTIYA
Associate Professor
Department of Philosophy
Faculty of Letters
Chiba University
Dates of visit: November 1986 - September 1987
Tutiya is interested in the development of speech acts theory within
the framework of situation theory and situation semantics. He is also
interested in quantification in Japanese, in Frege and the history of
logic after him, and has been translating "Situations and Attitudes"
into Japanese. He is an active participant in the STASS project.
SUSON YOO
Doctoral Candidate and Instructor
Department of Linguistics
Korea University
Dates of visit: March 1987 - February 1988
Yoo is continuing her work with Kiyong Lee, currently at CSLI, and is
especially interested in learning more about situation theory and
unification grammar and investigating their universal ramifications by
testing their linguistic significance and computational applicability
to the analysis of Korean.
LOTFI ZADEH
Professor
Department of Computer Science
University of California, Berkeley
Dates of visit: Fall Quarter 1987
Zadeh developed "fuzzy" logic and set theory -- the central idea being
that truth or membership in a set isn't simply binary, but permits a
continuum of values. He has attended many CSLI functions over the
past four years, especially on Thursdays, and we are pleased that he
has arranged to be here several days a week during fall quarter.
∂07-Jan-88 0149 RESTIVO@Sushi.Stanford.EDU PROLOG Digest V6 #5
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 88 01:49:15 PST
Date: Wed 6 Jan 1988 09:33-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SUSHI.STANFORD.EDU>
Reply-to: PROLOG@SUSHI.STANFORD.EDU
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V6 #5
To: PROLOG@SUSHI.STANFORD.EDU
PROLOG Digest Thursday, 7 Jan 1988 Volume 6 : Issue 5
Today's Topics:
Implementation - Strings
----------------------------------------------------------------------
Date: Thu, 31 Dec 87 11:32:44 EST
From: Michael Covington <MCOVINGT%UGA.BITNET@forsythe.stanford.edu>
Subject: Strings & Back Patting
In regards to Richard O'Keefe's article on string concatenation
(Prolog Digest, Volume 5, Number 100): He has certainly hit the nail
on the head in pointing out the utility of formatted i/o (i.e.,
predicates analogous to printf and scanf in C). If I can remember
right, _all_ of the string handling in our forthcoming textbook
(Prolog Programming in Depth, by Covington, Nute, and Vellino) was
motivated by the lack of a formatted i/o package. Some Prologs have
these, but we were writing highly portable Prolog and couldn't rely on
anything.
The more general point is well taken -- string processing within a
program is usually a substitute for something that could be done better
with Prolog data structures. Take your input, parse it up into meaningful
data structures as soon as possible, and convert it back to characters
at the very moment of output.
------------------------------
Date: 5 Jan 88 18:25:25 GMT
From: lagache@violet.Berkeley.EDU (Edouard Lagache)
Subject: String operations in PROLOG: some comments.
I was quite intrigued by Richard A. O'Keefe's comments on the need (or
lack of) string operations in PROLOG. He focused on the question of
concatenation. However, there is a number of basic operations that are
required for decent string handling. As a reference one can take the
"C" string library, which includes (among others):
index = locate a character from the beginning of a string.
strcat = Concatenate two strings.
strcpy = Create a copy of a string.
strcmp = Compare two strings.
strlen = return the length of a string.
"mid$" = Returns a substring between specified intervals (non-
standard, but easily implemented).
I think that some of the above functions do have a place in a
PROLOG predicate library. 'strcmp', for example, is a very useful tool
for making sense of string data, and 'index' and 'mid$' can be used to
get at embedded control characters in strings that represent anything
from device control instructions, to templates for creating pseudo
natural language output.
However, there is a larger issue related to this question. Much
of the work with strings is dumb old procedural operations. Since
procedural operations run counter to PROLOG's way of doing business,
there is an obvious friction involved. There is two ways to resolve
that friction: One way is to try to come up with string primitives that
deal with all the procedural tasks internally and yet represent a
"useful" declarative concept for PROLOG programmer. I suppose that is
what Dr. O'Keefe is seeking, and trying to come up with such primitives
will require much thought and reflection from the PROLOG user
community.
The other approach would be to permit a real dichotomy between
procedural tasks and declarative programming via a second programming
language interface. Several PROLOGs now can call "C" functions, and in
some sense mixing "C" or LISP with PROLOG permits users to have the
best of both worlds.
The risk with that second approach is potential poisoning of the
declarative style of PROLOG with poorly chosen "C" interfaces. Thus,
in some sense we are reduced back the first option. Even if individual
programmers have the freedom to write procedural routines to interface
to PROLOG, those routines must be written to support and enhance the
logical structure of the PROLOG program they are written for.
In that sense PROLOG is a very demanding language, but I suppose
that is where its real power resides.
-- Edouard Lagache
P.S. I don't know how other PROLOGs are set up with respect to string
and/or atom manipulatives. It may well be the case that most of
my points are mute on the more potent PROLOGs.
------------------------------
Date: Wed, 6 Jan 88 00:14:20 PST
From: quintus!ok@Sun.COM (Richard A. O'Keefe)
Subject: Strings
Lagache's message is sensible, but doesn't quite address the
point I am interested in. He says
> I think that some of the above functions do have a place in a
> PROLOG predicate library.
and
> One way is to try to come up with string primitives that
> deal with all the procedural tasks internally and yet represent a
> "useful" declarative concept for PROLOG programmer. I suppose that is
> what Dr. O'Keefe is seeking, and trying to come up with such primitives
> will require much thought and reflection from the PROLOG user
> community.
(1) The whole point of my original message was that I do *NOT* think
that strings (and therefore, operations on strings) should be in
Prolog. Data interchange with a host language such as Lisp which
has a string data type is a good reason for supporting strings at
some level (making (=)/2, compare/3, and write/1 do something
sensible with them), but my position is that Prolog has no need
of strings for its own sake.
(2) I am not interested in the question "what is a good set of operations
for strings". I think I already know the answer. Quintus customers
with release 2.0 or later have it. Yes, it did take a couple of
years of thought. The answer is by APL out of Interlisp, with me as
midwife rather than inventor. The cornerstone of the Quintus strings
library is the predicate
midstring(ABC, B, AC, LenA, LenB, LenC)
which is true when ABC, B, and AC are all the same kind of text
object (that is, all three are strings or all three are atoms),
and there are text objects A and C such that
ABC = A // B // C
AC = A // C
and LenA, LenB, and LenC are the lengths of A, B, and C respectively.
Strictly speaking, all you really need is the operation I proposed
back in 1984:
string_chars(String, Chars)
which is true when String is a string, Chars is a list of character
codes, and they represent the same sequence of characters.
The operations in the Quintus Prolog library(strings) package work
together very nicely, and are as multi-directional as I could make
them.
Lagache says
> [O'Keefe] focused on the question of
> concatenation. However, there is a number of basic operations that are
> required for decent string handling. As a reference one can take the
> "C" string library
(3) I focussed on concatenation for a very simple reason.
My previous message was about the question:
Is there any good reason, other than compatibility with a
host language which provides strings, to have strings AT ALL
in Prolog?
This suggested a related questions:
How do people USE string operations when they are available?
Are these good ways, or would something else be better?
Concatenation is the most commonly used string operation. (Note
that midstring/6 is concatenation, finding length, search,
inserting, deleting, or extracting a substring, or lots of other
things, depending on how you call it.)
I examined one particular program which used concatenation heavily,
and found that in nearly every case it was inappropriate. My
previous message had a list of some of these uses, and suggested
more appropriate things to do.
The question remains open: other than communication with another
language which has strings, are there any applications for which
string operations are the best choice in Prolog, rather than say
lists of character codes or atoms. I was hoping for responses from
people who had practical experience of using strings in Prolog (or
Lisp for that matter). In particular, I would like to see responses
of the form
"I use strings to solve such and such a problem.
Here is a sketch of the code."
If any responses come up, I mean to justify my opinion against
strings (it is NOT a prejudice, because when I started programming,
I thought strings were a wonderful idea) by suggesting ways of
solving the same kind of problem in Prolog without the use of strings.
If I can't do this, or if the non-string solutions turn out to be
intrinsically inefficient, I shall admit that I was wrong.
(4) The reason why C is such a good language for text processing is
that it HASN'T got a built-in string data type. The C library
actually supports three different string representations:
str*() functions : terminated by NUL only
strn*() functions : terminated by a count or NUL, whichever
runs out first
mem*() functions : terminated by a count only
Version 6+ UNIX also included a "big strings" package, I believe
that the bc(1) utility used it. The package disappeared in later
UNICes. I have my own C strings package which provides about 110
functions (some of them macros). I am thoroughly familiar with
the string operations in C (the standard ones and the Lattice C
ones, I don't know Whitesmiths C at all). I am surprised that
anyone would suggest taking them as a model. (There is no
standard operation for taking a substring or for searching for
a given string.) When the Quintus strings package was designed,
I considered APL, Interlisp, Common Lisp, PL/I, and SNOBOL. I'm
not sure what Scheme has, but T hasn't got anything Common Lisp
hasn't.
Lagache specifically mentions the following operations:
> index = locate a character from the beginning of a string.
> strcat = Concatenate two strings.
> strcpy = Create a copy of a string.
> strcmp = Compare two strings.
> strlen = return the length of a string.
> "mid$" = Returns a substring between specified intervals (non-
standard, but easily implemented).
(5) I repeat that my original question was "is there any practical
reason to have strings AT ALL", not "what string operations
should there be". All of these operations (with the exception
of strcpy()) are useful, and should be synthesisable.
Let's see first how we could implement these operations using
midstring/6 plus the existing built-in operations, and then how
we would implement them with lists of character codes.
index(Whole, Part, Offset) :-
midstring(Whole, Part, _, Offset, _, _).
strcat(A, B, AB) :-
midstring(AB, B, A, _, _, 0).
strcpy(X, X).
strcmp(Order, X, Y) :-
compare(Order, X, Y).
strlen(Text, Length) :-
midstring(Text, Text, 0, Length, 0).
'mid$'(Whole, Offset, Length, Part) :-
midstring(Whole, Part, _, Offset, Length, _).
So adding midstring/6 and string_chars/2, plus extending (=)/2,
compare/3, and write/1, appears to be a sufficient basis for
synthesising the required operations. Which is not to say that
this is the best interface for the programmer.
How would we do this using lists of character codes?
index(List, Pattern, Offset) :-
index(Pattern, Offset, List, _).
index(Pattern, Offset) -->
len(Offset),
Pattern.
strcat(A, Z, AZ) :-
append(A, Z, AZ).
strcpy(X, X).
strcmp(Order, X, Y) :-
compare(Order, X, Y).
strlen(List, Length) :-
length(List, Length).
'mid$'(List, Drop, Take, Section) :-
'mid$'(Drop, Take, Section, List, _).
'mid$'(Drop, Take, Section) -->
len(Drop),
len(Take, Section).
The non-terminals len(L) and len(L,V) mimic the SNOBOL constructs
LEN(L) and LEN(L) $ V respectively. A variable in a grammar rule
mimics the SNOBOL construct *Pattern. Thus index/3 is true
when after skipping Offset items in List there is something that
matches Pattern, and 'mid$'/4 is true when after skipping Drop
items from List the next Take items match the list Section.
'mid$'/4 is multi-directional. The Pattern argument of index/3
cannot be solved for, but that is because it can be anything that
would be legal as the body of a grammar rule. A list is of course
just such a legal body.
I just stopped and benchmarked this version of 'mid$' against
the byte-vector version, hoping for a clear result. But sometimes
one was faster and sometimes the other.
(6) The question/challenge remains:
what, if anything, are strings *better* for?
Remember: if you are generating output, it is better to avoid
strings entirely. What are strings better than trees for,
internally?
------------------------------
End of PROLOG Digest
********************
∂07-Jan-88 0947 @SUMEX-AIM.Stanford.EDU:Acuff@Sumex-AIM.Stanford.EDU Explorer II upgrades
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 88 09:47:31 PST
Received: from KSL-EXP-1 by SUMEX-AIM.Stanford.EDU with TCP; Thu, 7 Jan 88 09:42:16 PST
Message-Id: <2777564297-7332438@KSL-EXP-1>
Sender: Acuff@KSL-EXP-1
Date: Thu, 7 Jan 88 09:38:17 PST
From: Richard Acuff <Acuff@Sumex-AIM.Stanford.EDU>
To: aap@aim
Subject: Explorer II upgrades
The two Explorer II and 16MB memory upgrades for the AAP have arrived.
Which machines would you like them in? It is reasonably easy to switch
from machine to machine, though not so you'd want to do it every day,
but enough that you could place the upgrades into machines used by
people doing heavy work, then move them to the next person running
experiments, etc.
-- Rich
∂07-Jan-88 1136 emma@russell.stanford.edu CSLI Calendar, January 7, 3:12
Received: from RUSSELL.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 88 11:35:57 PST
Received: by russell.stanford.edu (3.2/4.7); Thu, 7 Jan 88 10:43:48 PST
Date: Thu, 7 Jan 88 10:43:48 PST
From: emma@russell.stanford.edu (Emma Pease)
To: friends@russell.stanford.edu
Subject: CSLI Calendar, January 7, 3:12
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
7 January 1988 Stanford Vol. 3, No. 12
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR NEXT THURSDAY, 14 January 1988
12 noon TINLunch
Ventura Hall Reading: "A Border Dispute"
Conference Room by John MacNamara
Discussion led by John Perry
(John@alan.stanford.edu)
Abstract below
3:30 p.m. Tea
Ventura Hall
--------------
NEXT WEEK'S TINLUNCH
Reading: A Border Dispute
by John Macnamara
Discussion led by John Perry
(john@alan.stanford.edu)
14 January
Macnamara's "A Border Dispute" has as its nominal aim to argue for a
thesis about the relation of logic to psychology. Macnamara's view is
that logic is not a part of psychology, but provides a competence
theory for psychology. He feels this view avoids the pitfalls of
psychologism, but provides for the particularly intimate relation he
sees between logic and psychology.
Most of the book consists of studying what competences a language
learner must have, given what recent philosophers of language have
shown (or at least said) about such issues as reference, identity,
sortals, and the like.
I am not quite sure what to think of the book, but I have to make
up my mind, as I owe someone a review, and it is overdue. I am (a) a
little puzzled by the relation between Macnamara's main thesis and the
project that takes up the bulk of the book, (b) a little suspicious of
the commitment to a language of thought (c) not too happy with his
account of what is required to learn how to use "I". But I am not
sure (c) gets to the central issues. And Macnamara is so sensible
about many things, that I am inclined to trust him where I don't
understand him. I am hoping people at tinlunch will help clarify the
basic issues a review should address, and perhaps even tell me what I
should think about them.
--------------
CSLI TALK
Phoneme Recognition Using Time-Delay Neural Networks
Dr. Alex Waibel
1:00-2:30, Friday, 8 January 1988
Ventura Trailer C/D
Dr. Alex Waibel of Carnegie-Mellon University is currently a visiting
researcher at ATR in Osaka, Japan, and will be at Stanford and CSLI,
Friday, 8 January.
∂07-Jan-88 2110 LOGMTC-request Logic seminar
Received: from RUSSELL.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 88 21:10:38 PST
Received: by russell.stanford.edu (3.2/4.7); Thu, 7 Jan 88 21:13:50 PST
Date: Thu 7 Jan 88 21:13:49-PST
From: Sol Feferman <SF@Russell.Stanford.EDU>
Subject: Logic seminar
To: logmtc@SAIL.STANFORD.EDU
Message-Id: <568617229.0.SF@Russell.Stanford.EDU>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@Russell.Stanford.EDU>
Speaker: Prof. Masahiko Sato, Taohλλλohoku Universityλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλ
Speaker: Prof. Mashikoλλλλahiko Sato, TOhλλohoku University
Title: Symbolic Set Tehλλheory
Time: Tues. Jan. 12, 4:15-5:30
Place: Room 381-T, Math. Bldg. Stanford
S. Feferman
Abstract:
We will present an intuitionistic first order theory SST (Symbolic Set Theory).
It is a theory of symbolic expresseλions by symbolic expressions in the esnλλλsense
that the syntax of the theory is given by symbolic expressions. SSt providsλesλλλλλλλλλλT provides
a Lisp like programming language whose sematnicsλλλλλλantics is given in terms of
evaluation predicate s Iλ|> v. When s|>vλ λv holds, we say that the program
s has the value v. Two programs s and t are equal (s+λ=t) if they have the
same value.
A predicative set theory somehaλλλ λwλλmewhat similar of Martin Lof's type theory will
be developed in SSt, where, unlike Martin-Lof, equality between sets is
given by the computational equality above.
M. Sato
-------
∂08-Jan-88 0925 DELAGI@SUMEX-AIM.Stanford.EDU Re: Explorer II upgrades
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Jan 88 09:25:45 PST
Date: Fri, 8 Jan 88 09:22:29 PST
From: Bruce Delagi <DELAGI@SUMEX-AIM.Stanford.EDU>
Subject: Re: Explorer II upgrades
To: Acuff@SUMEX-AIM.Stanford.EDU
cc: aap@SUMEX-AIM.Stanford.EDU
In-Reply-To: <2777564297-7332438@KSL-EXP-1>
Message-ID: <12364997971.39.DELAGI@SUMEX-AIM.Stanford.EDU>
I suggest x10 in its new location be one of the two, that x7 (the file server)
beswapped with x8 (the machine in the corner near Greg and Max), and that x8
be the other upgraded machine.
/b
-------
∂08-Jan-88 1326 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talks
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Jan 88 13:26:01 PST
Date: Fri 8 Jan 88 11:43:45-PST
From: Anil R. Gangolli <GANGOLLI@Sushi.Stanford.EDU>
Subject: Upcoming AFLB Talks
To: aflb.all@Sushi.Stanford.EDU
Office Phone: (415) 723-3605
Message-ID: <12365023688.9.GANGOLLI@Sushi.Stanford.EDU>
PLEASE NOTE:
* We desperately need speakers for this quarter. If you
would like to talk, please contact me: gangolli@SUSHI.STANFORD.EDU
THIS WEEK'S TALK:
14-January-88: Nathan Linial (IBM Almaden)
Distributive Graph Coloring:
Global Solutions From Local Data
We deal with the following model of distributed computing: The
processors reside at the vertices of a graph G and have distinct ID's
in the range 1,..,n. The computation is synchronous and reliable,
there is no bound on message lengths and computing is for free. This
is an artificial model which focuses only on what is the diameter of
the neighborhood from which each processor collects data. In
aprticular all problems can be solved at time diameter(G).
The following three results are proved:
- The n-cycle cannot be 3-colored faster than log*n (and this is tight
by previous work) and cannot be 2 colored faster than cn.
- The d-regular tree cannot be colored with root(d) colors faster than
diameter/3.
- Every graph may be O(D**2) colored at time O(log*n) where D is the
largest
degree.
More realistic models for distributed systems will be mentioned where
the computations must be local.
NEXT WEEK'S TALK:
21-January-88: Nancy Amato (UC Berkeley)
An O(n↑2 logn) Solution to the
Scientific American Train Problem
The following problem appeared in the "Computer Recreations" column by
A.K. Dewdney in the June 1987 issue of the Scientific American. The
problem has its origins around the turn of the century. In the
October and November issues he discusses some solutions.
There is a train chugging along a straight stretch of track from
station A to station B. The engineer realizes he needs to return to
station A and is not very excited about the prospect of backing the
train all the way. Luckily there is a short spur line off to the right
side of the track. It is just large enough to hold one car and and has
a switch for either direction of track.
The engineer must use this spur line to turn the entire train around.
This entails reversing the ordering of the cars, and the orientation
of each individual car. We count one unit of work as moving one car
one car-length on the track. Dewdney has an O(n↑3) solution, where n is the
number of cars, and he challenges his readers to do better.
We present an O(n↑2 logn) algorithm for solving a variation of this
problem in which all cars are taken to be locomotives, i.e. we have n
self-propelled cars. We then outline a proof that the algorithm can
be simulated by the original single-locomotive train with at most a
constant-factor time loss.
-------
∂08-Jan-88 1652 emma@russell.stanford.edu CSLI Talk
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 8 Jan 88 16:52:25 PST
Received: by russell.stanford.edu (3.2/4.7); Fri, 8 Jan 88 16:23:01 PST
Date: Fri, 8 Jan 88 16:23:01 PST
From: emma@russell.stanford.edu (Emma Pease)
To: friends@russell.stanford.edu
Subject: CSLI Talk
CSLI TALK
LOQUI : a Natural Language Interface
Jean-Louis Binot
Belgium Institute for Management
2:15, Tuesday, 12 January
Ventura Trailer Classroom
LOQUI, a natural language interface for English and German implemented
in BIM_Prolog, constitutes the NL component of Esprit project 107 and
is the result of a collaborative effort involving BIM, Scicon and the
University of Hamburg. The current prototype runs on SUN workstations
and interfaces a database on project management.
LOQUI is probably one of the most ambitious attempts so far to
implement a natural language system based on highly advanced
linguistic theories within a logic programming environment. The
parsers are based on the modern and widely accepted framework of
unification based grammars. The database interface is established
directly at the tuple level so as to take full advantage of the logic
programming facilities. Responses from the system are processed by
the generation components and cast into natural replies in English or
in German.
Throughout, special emphasis has been put on supporting truly natural
interaction with the user. To this end, LOQUI includes a discourse
manager constructing and exploiting an explicit representation of the
discourse structure. The system also has a highly modular
architecture, which is organised around a domain independent semantic
representation that is interpreted on the basis of a knowledge base
modelling the application domain. The latter two features account for
an especially high degree of flexibility and portability and rank
LOQUI among the most advanced systems of its kind.
We will discuss the design and realization of the current LOQUI system
and present a number of possible extensions.
∂09-Jan-88 1822 LOGMTC-request Logic seminar
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 9 Jan 88 18:22:33 PST
Received: by russell.stanford.edu (3.2/4.7); Sat, 9 Jan 88 18:25:46 PST
Date: Sat 9 Jan 88 18:25:44-PST
From: Sol Feferman <SF@Russell.Stanford.EDU>
Subject: Logic seminar
To: logmtc@SAIL.STANFORD.EDU
Message-Id: <568779944.0.SF@Russell.Stanford.EDU>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@Russell.Stanford.EDU>
The following announcement was received garbled by some adressees.
Speaker: Prof. Masahiko Sato, Tohoku University
Title: Symbolic Set Theory
Time: Tues. Jan. 12, 4:15-5:30 PM
Place: Room 381-T, Math. Bldg. , Stanford
S. Feferman
-------
∂10-Jan-88 1057 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Tues Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Jan 88 10:56:59 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Sun 10 Jan 88 10:54:04-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA13310; Sun, 10 Jan 88 10:55:02 PST
Date: Sun, 10 Jan 88 10:55:02 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8801101855.AA13310@Tenaya.stanford.edu>
To: faculty@score
Cc: reis@sierra
Subject: Tues Lunch
The faculty lunch this Tuesday, Jan. 12, will feature a discussion led
by Prof. Michael Genesereth on policies for the 1988 CSD PhD
admissions process. 12:15 p.m., MJH 146. -Nils
∂10-Jan-88 1839 LOGMTC-request linear logic
To: logmtc@SAIL.Stanford.EDU
From: Carolyn Talcott <CLT@SAIL.Stanford.EDU>
There will be a working seminar to study Girard's paper on linear logic
this quarter. The goal is to get a better understanding of linear logic,
to find out precisely what contribution Girard has made, and to look into
the connections to computer science in more depth. The first meeting
(mainly organizational) will be Wed. Jan 13, at 3pm in 352 MJH.
∂11-Jan-88 1009 LOGMTC-request Reminder: CS359 starts Tuesday January 12, 1988
Received: from navajo.stanford.edu by SAIL.Stanford.EDU with TCP; 11 Jan 88 10:09:27 PST
Received: by navajo.stanford.edu; Mon, 11 Jan 88 10:05:20 PST
Date: Mon, 11 Jan 88 10:05:20 PST
From: Phokion Kolaitis <kolaitis@navajo.stanford.edu>
Subject: Reminder: CS359 starts Tuesday January 12, 1988
To: logmtc@sail.stanford.edu, students@score.stanford.edu
CS359 Computational Complexity and Finite Model Theory
Time: Tu-Th 11-12:15, First Day of Classes: Tuesday January 12, 1988
Room: Building 50 (English), Room 51B
Instructor: Phokion G. Kolaitis
Course Description:
The main goal of this course is to develop the connections between complexity
theory and logic on finite structures. Topics to be covered include:
logical characterizations of complexity classes; logics on finite structures,
with emphasis on fixpoint logic and its relation to logic programming;
Ehrenfeucht-Fraisse games and their appications; 0-1 laws on finite structures
and the complexity of the associated decision problems.
∂11-Jan-88 1030 LOGMTC-request mailing lists
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 11 Jan 88 10:29:04 PST
Received: from alan.stanford.edu by russell.stanford.edu (3.2/4.7); Mon, 11 Jan 88 10:32:15 PST
Received: by alan.stanford.edu (3.2/4.7); Mon, 11 Jan 88 10:32:56 PST
Date: Mon, 11 Jan 88 10:32:56 PST
From: barwise@alan.stanford.edu (Jon Barwise)
To: logic@alan.stanford.edu
Subject: mailing lists
Carolyn and I have now consolodated logic mailing lists. You can
send to either logic@alan or logmtc@sail, and the effect should be the
same.
∂11-Jan-88 1056 X3J13-mailer mailings
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 11 Jan 88 10:55:54 PST
Received: by labrea.stanford.edu; Mon, 11 Jan 88 10:56:00 PST
Received: from sunvalleymall.lucid.com by edsel id AA19685g; Mon, 11 Jan 88 10:49:25 PST
Received: by sunvalleymall id AA28780g; Mon, 11 Jan 88 10:52:13 PST
Date: Mon, 11 Jan 88 10:52:13 PST
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8801111852.AA28780@sunvalleymall.lucid.com>
To: x3J13@sail.stanford.edu
Cc: edsel!jlz@labrea.stanford.edu
Subject: mailings
This is a reminder that any subcommittee papers need to be mailed
by Friday 2/5 in order to reack committee members in time.
That's only 3 weeks from Friday folks...
---jan---
∂11-Jan-88 1221 @SUMEX-AIM.Stanford.EDU:Acuff@Sumex-AIM.Stanford.EDU Explorer II upgrades
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Jan 88 12:21:11 PST
Received: from KSL-EXP-1 by SUMEX-AIM.Stanford.EDU with TCP; Mon, 11 Jan 88 12:09:13 PST
Message-Id: <2777918803-12107559@KSL-EXP-1>
Sender: Acuff@KSL-EXP-1
Date: Mon, 11 Jan 88 12:06:43 PST
From: Richard Acuff <Acuff@Sumex-AIM.Stanford.EDU>
To: aap@aim
Subject: Explorer II upgrades
After some amount of discussion it looks like one Explorer II upgrade
will go into X10 in it's new home in A-1105 (where an 1186 used to be),
and one will be put into X3 on Nelleke Aiello's desk with the
understanding that AAP personnel wishing to use that machine can make
arrangements with her to get time on it (and will be allowed keys to
C-209). X3's upgrade will be installed soon, but Bruce Delagi has asked
that X10's wait until after his CARE class. Also, one unit was DOA so
we must wait for replacement.
-- Rich
∂11-Jan-88 1249 X3J13-mailer mailings
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 11 Jan 88 12:49:36 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Mon, 11 Jan 88 15:49:30 EST
Received: by kali.think.com; Mon, 11 Jan 88 15:49:26 EST
Date: Mon, 11 Jan 88 15:49:26 EST
From: gls@Think.COM
Message-Id: <8801112049.AA11904@kali.think.com>
To: x3J13@sail.stanford.edu
In-Reply-To: Jan Zubkoff's message of Mon, 11 Jan 88 10:52:13 PST <8801111852.AA28780@sunvalleymall.lucid.com>
Subject: mailings
I would like to appeal to all subcommittees to try very hard to submit
material for mailing to X3J13 members as Jan has requested. Failure to
use this mailing-out mechanism slows our progress by a factor of two!
(To see why, consider that a proposal based on feedback from the December
meeting can be voted on in March if mailed out ahead, but cannot be voted
on until June if first presented at the March meeting.)
We stand a very good chance of having a draft ready for public review by
December 1988 or maybe March 1989, *provided* that we make good use of time
by mailing proposals out ahead of meetings. Here is a plausible schedule,
if also an optimistic one:
February: Mail out current CLOS draft.
Mail out current error proposal draft.
Mail out cleanup proposals so far.
Mail out other proposals (character sets? iteration?).
March: Vote on all this stuff. Probably CLOS needs two more
iterations and error proposal needs one more iteration.
Some small fraction of cleanup proposals require iteration.
May: Mail out CLOS draft N-1.
Mail out error proposal draft M.
Mail out more cleanup proposals.
Last chance to mail other proposals without blowing the schedule.
Mail out whatever draft manual the editorial committee has so far.
June: Vote on CLOS draft; probably needs one more round.
Vote on error draft; with any luck this is final or
requires only very minor tweaking.
Vote on more cleanup proposals.
Vote on other proposals. Probably more work needed.
Provide feedback to editorial committee (now and by mail later).
August: Mail out CLOS draft N.
Mail out more cleanup proposals (the last ones???).
Mail out draft standard.
September: Vote on CLOS draft. With any luck this is final. (If we cannot
get a final vote by now, I despair of ever having one.)
Vote on cleanup proposals.
Vote on other proposals.
Provide lots of feedback to editorial committee.
November: Mail out reasonably final draft standard.
December: Vote on draft standard. Either it is ready for public review
or it isn't. (It need not be absolutely perfect, but should
be in good shape.) If it isn't, then another vote in March
is needed.
Such a schedule will demand hard work by the subcommittees, especially the
CLOS, cleanup, and editorial committees. I do know that Larry Masinter has
been working hard on the cleanup proposals, and the CLOS group met in
mid-December. Everyone else should only work so hard. If we do not have
the ambition to try for a schedule like this, then we are looking at a
public review in 1990 or beyond, at our present rate, and a standard
perhaps not until 1992. We need it much sooner than that.
Let's get cracking.
--Guy
∂11-Jan-88 1311 LOGMTC-request sorry about the confusion
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 11 Jan 88 13:11:24 PST
Received: from alan.stanford.edu by russell.stanford.edu (3.2/4.7); Mon, 11 Jan 88 13:14:36 PST
Received: from localhost by alan.stanford.edu (3.2/4.7); Mon, 11 Jan 88 13:15:24 PST
To: logic@alan.stanford.edu
Subject: sorry about the confusion
Date: Mon, 11 Jan 88 13:15:23 PST
From: Jon Barwise <barwise@alan.stanford.edu>
Yes, logic lunch was held today. But it was empty. The room was locked,
so people came and left. We will do better next Monday. See you then.
∂12-Jan-88 1353 barwise@alan.stanford.edu Summer internships
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 12 Jan 88 13:53:04 PST
Received: from alan.stanford.edu by russell.stanford.edu (3.2/4.7); Tue, 12 Jan 88 13:55:18 PST
Received: from localhost by alan.stanford.edu (3.2/4.7); Tue, 12 Jan 88 13:56:07 PST
To: ssp-students@alan.stanford.edu, ssp-faculty@alan.stanford.edu
Cc: symbolic@alan.stanford.edu
Subject: Summer internships
Date: Tue, 12 Jan 88 13:56:05 PST
From: Jon Barwise <barwise@alan.stanford.edu>
This is to remind you of the six summer internships that available
to SSP majors this coming summer. Each will pay roughly $2000/month, for
two or three months, depending on the desires of the intern.
These are provided by CSLI to help students get to work on research
with SSP faculty, either at Stanford, or with consulting faculty in
the AI Center at SRI or in the Intelligent Systems Lab at Xerox. There
are two internships for each place.
To apply, you should first figure out a project with one of the
faculty. Don't forget the consulting faculty. If you don't know any
of them, get a list of them in the Program Office, along with their
interests.
Applications should consist of:
1) A description of the propsed project, written by the
student
2) A letter of recommendation from some faculty member who is
familiar with your work
3) A letter of support from the proposed faculty advisor.
It is possible for (2) to be the same as (3), but not necessary.
Applications are due by the end of winter quarter, so that we can let
you know early enough to plan your summer.
Any questions should be directed to Dave Hilbert or me.
∂13-Jan-88 0902 BSCOTT@Score.Stanford.EDU Faculty and Staff Public Service Participation
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Jan 88 09:01:54 PST
Date: Wed 13 Jan 88 08:56:50-PST
From: Betty Scott <BSCOTT@Score.Stanford.EDU>
Subject: Faculty and Staff Public Service Participation
To: Faculty@Score.Stanford.EDU
cc: BScott@Score.Stanford.EDU
Message-ID: <12366304021.21.BSCOTT@Score.Stanford.EDU>
Nils received the following message from Mary Cloutier, Dean Gibbons'
secretary, requesting information on any public service roles of our faculty
or staff. There is urgency in this request. If you have a public service
role to report, please send your response directly to me by Thursday,
January 14.
Mary Cloutier's message:
"Dr. Gibbons received an em from Catherine Milton regarding Don Kennedy's
joining a Commission on Public Service. The press release for that
announcement will carry items on each school, listing particularly
public service projects that are of interest. He has asked that you
each get a copy of this message and give it high priority, thoughtful
attention. We will collect the data in the Dean's office and put it
together before sending it on to Catherine.
"As she needs it in the next few days, please get it to me as soon as
possible.
"Following is the message received:
'Don Kennedy has recently been appointed to the commission on the
Public Service chaired by Paul volker. The Commissionm is charged with
studying and developing action plans for improving the number and
quality of people entering federal government service.
'We will be developing a press release in the next few days to announce
Don's appointment. In this release we would like to highlight some of
the service activities at the various schools and departments at
Stanford. Are there any projects offered either by faculty, staff, or
students from the School of Engineering that you would like to have included
in the press release? Please send me an em in the next few days as we hope
to get the release out as soon as possible.
'I also hope we can get together in the near future to talk about ways the
Center and your School might work together again on some public service
activities. The support given by members of your faculty and staff to the
You Can Make A Difference Conferences was especially appreciated.'
"Please acknowledge receipt of this request and when we might expect your
input.
"Thank you.
Mary Cloutier"
--------------
Remember--please send your responses to me. --Betty
-------
∂13-Jan-88 1557 LOGMTC-request logic seminar
To: logmtc@SAIL.Stanford.EDU
From: Carolyn Talcott <CLT@SAIL.Stanford.EDU>
Title: Using Typed Lambda Calculus to Implement Logical
Systems on a Machine
Speaker: Ian Mason
Laboratory for Foundations of Computer Science
Edinburgh University
Time: Tuesday, January 19, 4:15-5:30
Place: 381T Math Bldg.
Abstract:
In recent years there has been a growing interest in using computers
as an aid for correctly manipulating logical systems. However,
implementing a proof environment for a specific logical system is both
complex and time consuming, this---together with the proliferation of
logics---suggests that a uniform and reliable alternative is
desirable. One such alternative is the Edinburgh Logical Framework
(LF), currently under development at the LFCS. The LF is a
logic-independent tool which, given a specification for a logical
system, synthesizes a proof editor and checker for that system. Its
specification language is based on a general theory of logics, which
enables one to capture uniformities and idiosyncrasies of a large
class of logics without sacrificing generality for tractability.
Peculiarities (such as side conditions on rule application, variable
occurrence or formula formation) are expressed at the level of the
specification.
In this talk we will illustrate the applicability of LF and discuss to
what extent it is successful. The analysis (of the formal
presentation) of a system carried out through encoding often
illuminates the system itself. We will also deal with this phenomenon.
∂13-Jan-88 1602 LOGMTC-request linear logic
To: logmtc@SAIL.Stanford.EDU
From: Carolyn Talcott <CLT@SAIL.Stanford.EDU>
The working seminar to study Girard's paper on linear
logic will meet 2:15 to 3:15 Wednesdays.
The room will be 352 MJH except for next Wednesday
when we will meet in 301 MJH.
We will begin with the section on phase semantics
and Gian Luigi Bellin will present the material
in that section.
∂13-Jan-88 1604 FACIL-mailer Ncube Computer Meeting 1/13/87
To: "@BRAQUE.DIS[PUB,LES]"@SAIL.Stanford.EDU
CC: facil@SAIL.Stanford.EDU, Nilsson@Score.Stanford.EDU
From: Les Earnest <LES@SAIL.Stanford.EDU>
Attendees: Maryamni Awang, Jim Ball, Tom Dienstbier, Les Earnest (chair),
Stu Grossman, Anoop Gupta, Roland Horne, Ernst Mayr.
The purpose of the meeting was to develop an operating plan for the Ncube
computer that we call Braque, which was donated to Stanford by the Shell
Development Corporation a couple of years ago and has been operated until
now on a free but limited-service basis by CSD-CF. It came with free
maintenance, which has now run out, and does not yet have a proper
ethernet connection.
Ethernet handware and software will reportedly become available very soon,
perhaps in a couple of weeks, at a one-time cost of $4,200. Vendor
software maintenance will cost $4,000/year. Ncube is willing to do hardware
maintenance on a time-and-materials basis. Anoop Gupta thinks that the
system would require a memory upgrade in order to be interesting to his
group, and will investigate the cost of getting that.
Representatives of just three prospective user groups attended the
meeting, led by Gupta (CIS), Horne (Petroleum Engineering), and Mayr
(Computer Science). It appears that the most plausible operating plan
would be to have one group take responsibility for the system and
negotiate cost-sharing support agreements with other interested parties.
Anoop will look into the question of whether CIS would like to take the
lead role.
If this computer fails to find a home, it will be necessary to surplus it.
Les Earnest
CS Facilities Committee Chair
∂13-Jan-88 1635 emma@russell.stanford.edu CSLI Calendar, January 14, 3:13
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 13 Jan 88 16:34:58 PST
Received: by russell.stanford.edu (3.2/4.7); Wed, 13 Jan 88 16:10:40 PST
Date: Wed, 13 Jan 88 16:10:40 PST
From: emma@russell.stanford.edu (Emma Pease)
To: friends@russell.stanford.edu
Subject: CSLI Calendar, January 14, 3:13
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
14 January 1988 Stanford Vol. 3, No. 13
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 14 January 1988
12 noon TINLunch
Ventura Hall Reading: "A Border Dispute"
Conference Room by John MacNamara
Discussion led by John Perry
(John@alan.stanford.edu)
Abstract in last week's Calendar
3:30 p.m. Tea
Ventura Hall
--------------
CSLI ACTIVITIES FOR NEXT THURSDAY, 21 January 1988
2:15 p.m. CSLI Seminar
Room G-19 Factorization in Grammar:
Redwood Hall What we can learn about grammar design from Chichewa
Joan Bresnan
(bresnan@alan.stanford.edu)
Abstract below
3:30 p.m. Tea
Ventura Hall
--------------
NEXT WEEK'S SEMINAR
Factorization in Grammar:
What we can learn about grammar design from Chichewa
Joan Bresnan
bresnan@alan.stanford.edu
21 January
Languages that differ typologically from English can yield striking
insights about the universal design of grammar. I will present for
the CSLI audience highlights from recent research by Bresnan and
Kanerva on Chichewa, a Bantu language spoken in East Central Africa.
∂13-Jan-88 1723 TAJNAI@Score.Stanford.EDU SUNRISE CLUB MEETS JANUARY 26, 1988
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Jan 88 17:22:55 PST
Date: Wed 13 Jan 88 17:18:50-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: SUNRISE CLUB MEETS JANUARY 26, 1988
To: faculty@Score.Stanford.EDU, PHD@Score.Stanford.EDU,
CSL-students@Sierra.Stanford.EDU
cc: Thiery@Mojave.Stanford.EDU
Message-ID: <12366395408.17.TAJNAI@Score.Stanford.EDU>
The Sunrise Club will meet on Tuesday, January 26 at 7:30 a.m. in
the Oak Lounge West, Tresidder Union. All CSD/CSL faculty
and graduate students are cordially invited.
Professor John Cioffi of the Information Systems Laboratory,
EE Dept., will speak on "Storage Channel Equalization: A Signal
Processing Means by Which to Increase Density in Commercial
Disk Storage Systems".
Breakfast will be served, so we'd appreciate your R.S.V.P.
reply to me.
Carolyn Tajnai
-------
∂14-Jan-88 1351 AAAI-OFFICE@SUMEX-AIM.Stanford.EDU [AAAI <AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>: new committee chairs]
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Jan 88 13:51:31 PST
Date: Thu, 14 Jan 88 13:35:42 PST
From: AAAI <AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>
Subject: [AAAI <AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>: new committee chairs]
To: officers: ;
Telephone: (415) 328-3123
Postal-Address: 445 Burgess Drive, Menlo Park, CA 94025
Message-ID: <12366616931.54.AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>
For those who have not responded to the message below regarding
the selection of new committee chairs and committees, could you
please review it and respond as soon as possible?
Thank
---------------
Mail-From: AAAI-OFFICE created at 8-Jan-88 12:10:54
Date: Fri, 8 Jan 88 12:10:54 PST
From: AAAI <AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>
Subject: new committee chairs
To: clancey@SUMEX-AIM.Stanford.EDU
cc: aaai-OFFICE@SUMEX-AIM.Stanford.EDU
Telephone: (415) 328-3123
Postal-Address: 445 Burgess Drive, Menlo Park, CA 94025
Message-ID: <12365028629.15.AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>
Date: Thu, 31 Dec 87 12:54:21 PST
From: AAAI <AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>
Subject: New Committees and Chairs
To: officers: ;
cc: aaAI-OFFICE@SUMEX-AIM.Stanford.EDU
Telephone: (415) 328-3123
Postal-Address: 445 Burgess Drive, Menlo Park, CA 94025
Message-ID: <12362939386.28.AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>
Happy New Year!
During the Fall, the Executive Committee reviewed the current composition
of the existing committees and suggested that some committee chair positions
needed to change. The Execom devised a method of chair rotation which ensures
continuity and progression.
It was decided that the current chair would remain on the committee in a
steering position for 2 years. The new chair would be the standing chair
for the same period of time and would nominate his/her successor.
This procedure would apply for the following committees: Finance, Publications,
Fellowship, Scholarship, Conference and Workshops. The other committees,
Nominating, Program, and Symposium, usually rotate chairs annually.
But, before we begin to review the list of chair nominations, we need to
approve the following new committees. During the past Council meetings,
we have organize and/or nominated new committees, but we have not formally
voted on their existence. According to the bylaws, the Council, "by a
resolution adopted by an affirmative majority vote of the number of
councilors in office provided a quorum is present, may designate
one or more committees."
The charters of the following new Committees are:
FELLOWSHIP COMMITTEE: Committee will solicit, review and monitor nominations
for post-doctoral fellowships which will be for a two year span.
SCHOLARSHIP COMMITTEE: Committee will review and select students to
receive grants to attend the National Conference on Artificial Intelligence.
SYMPOSIUM COMMITTEE: Committee is responsible for the selection of topics
and their chairs and overseeing the Series's program development.
PLEASE VOTE ON THE FOLLOWING COMMITTEES:
YES NO
FELLOWSHIP COMMITTEE
SCHOLARSHIP COMMITTEE
SYMPOSIUM COMMITTEE
*************************************************************************
If all the new committees have been approved, the following people
have been nominated (and contacted) for these committees. They are:
YES NO
SCHOLARSHIP ---
Raj Reddy
SYMPOSIUM ---
Hector Levesque
Nominees to the Fellowship Committee is still pending.
For the rest of the standing committees, here are the nominees:
YES NO
CONFERENCE ---
Howard Shrobe
FINANCE ---
Bruce Buchanan
WORKSHOP ---
Peter Hart
Chair nominations to the Publication Committee are still pending.
The chairs of the Nominating and Program Committee have not
been nominated.
Could you please vote on these nominations and return your response
by January 15?
Thank you for your attention to this important matter!
Claudia
PS We're planning to hold a spring Council meeting on Friday, March 25
(the day after the Symposium Series) in Palo Alto. I need to know your
thoughts on the issues for discussion and the proposed date of the
meeting.
-------
-------
-------
-------
∂14-Jan-88 1513 @Score.Stanford.EDU:ZM@SAIL.Stanford.EDU Suggestions for visiting faculty
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Jan 88 15:13:05 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 14 Jan 88 15:10:15-PST
Date: 14 Jan 88 1511 PST
From: Zohar Manna <ZM@SAIL.Stanford.EDU>
Subject: Suggestions for visiting faculty
To: faculty@Score.Stanford.EDU
The visiting-prof. committee (Manna, Mitchell, Talcott) invites
suggestions for the visiting faculty slot for 1988-9 (1 to 3 quarters).
Deadline for suggestions - January 31.
Zohar
∂14-Jan-88 1606 DEWERK@Score.Stanford.EDU CSD Course Notes Policies
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Jan 88 16:06:47 PST
Date: Thu 14 Jan 88 16:01:44-PST
From: Gerda de Werk <DEWERK@Score.Stanford.EDU>
Subject: CSD Course Notes Policies
To: instructors@Score.Stanford.EDU, tas@Score.Stanford.EDU
cc: dewerk@Score.Stanford.EDU, sloan@Score.Stanford.EDU,
davis@Score.Stanford.EDU
Message-ID: <12366643517.30.DEWERK@Score.Stanford.EDU>
This is to remind you of the CSD policies for course notes charges.
1) These policies apply to in-class students, SITN students, and
auditors.
2) Students are not charged for homework assignments, sample
solutions, and exams.
3) For other handouts, the first 50 pages are free and
students should be charged 3 cents/page thereafter.
4) Estimate the total number of copies at the beginning of the
quarter and charge the students at that time.
5) Checks should be made payable to "Stanford University" and
please note the course number on the check.
6) The Instructor or TA should collect the checks and bring them
to Tina Jimenez (TAC Secretary) or Thea Davis (MJH Receptionist).
(Please do not keep the checks too long.)
PLEASE NOTE: If you have a packet which will require a minimum of
10,000 pages, there is a service which will make the copies and sell
them directly to the students at 3 cents/page. For more information
about this service, please contact GODOT at 856-6138.
Thank you for your cooperation.
-Gerda
-------
∂14-Jan-88 2009 HADDAD@Sushi.Stanford.EDU BATS: Bay Area Theory Seminar, Feb 19.
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Jan 88 20:08:59 PST
Date: Thu 14 Jan 88 19:32:41-PST
From: Ramsey Haddad <HADDAD@Sushi.Stanford.EDU>
Subject: BATS: Bay Area Theory Seminar, Feb 19.
To: aflb.su@Sushi.Stanford.EDU, su-events@Sushi.Stanford.EDU
Message-ID: <12366681917.18.HADDAD@Sushi.Stanford.EDU>
Xerox PARC will host a BATS on Friday, February 19. The
talks will be:
"Lower Bounds on the Strength of Cryptographic Assumptions"
Steve Rudich, UC-Berkeley
"A Tradeoff between Space and Efficiency for Routing Tables"
David Peleg, Stanford
"Construction and Application of Euclidean Maximum Spanning Trees"
Frances Yao, Xerox
"Covering Orthogonal Polygons with Convex and Star Polygons"
Arvind Raghunathan, UC-Berkeley
Abstracts, driving directions, etc. will be sent later.
-------
∂15-Jan-88 0751 @Score.Stanford.EDU:CORNELIUS@SUMEX-AIM.Stanford.EDU Your last chance!
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Jan 88 07:51:40 PST
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 15 Jan 88 07:48:29-PST
Date: Fri, 15 Jan 88 07:49:22 PST
From: Craig Cornelius <Cornelius@SUMEX-AIM.Stanford.EDU>
Subject: Your last chance!
To: students@score.Stanford.EDU, csl-students@sierra.Stanford.EDU
cc: faculty@score.Stanford.EDU
Message-ID: <12366816027.17.CORNELIUS@SUMEX-AIM.Stanford.EDU>
This is one last reminder about the student poster session at the 20th
Annual Meeting of the Stanford Computer Forum on Feb. 10. This is an
exciting opportunity for you to share your research and present your
ideas to an interested audience. There are also facilities for a few
demonstrations at the poster session, too.
The format is informal: Posters are displayed around a large room (in
CERAS Hall). At any given time, about 1/2 of the posters are
accompanied by a presenter, who answers questions and explains the
research to any and all who stop by. The posters will be displayed
from 1:30 till 4:00 on Feb. 10.
You should work out the topic and format of your poster in
consultation with your research director. The material should be
aimed at an intelligent audience that is generally knowledgable about
computers, but not necessarily acquainted with the particular problem
and project you are presenting.
As "czar" of this activity, I need to know the following from
participants: (a) your name, (b) your topic, (c) your advisor,
definitely by mid-January. By the very latest, I need these, plus a
short (less than 1/2 page) abstract of the poster by Jan. 19, Tuesday.
If you'd like to present a demonstration using your computer
equipment, please let me know VERY SOON, since setting up demos will
require special arrangements.
Of course, please feel free to contact me with questions and
suggestions. I have several excellent posters prepared by KSL
students that you may examine for ideas on presentation.
Craig Cornelius
"Poster Czar" and Research Associate
725-3806
-------
∂15-Jan-88 1105 FACIL-mailer Home for Ncube
To: "@BRAQUE.DIS[PUB,LES]"@SAIL.Stanford.EDU,
facil@SAIL.Stanford.EDU
CC: Nilsson@SCORE.STANFORD.EDU
From: Les Earnest <LES@SAIL.Stanford.EDU>
Anoop Gupta reports that upgrading the Ncube computer to 512k bytes per
processor and ancillary costs would amount to $60,000, which is more than
anyone seems to be interested in spending. Nevertheless, his CIS group
is interested in adopting the machine and they plan to get it connected to
ethernet. It would be available to other groups on a cost sharing basis.
I recommend that the CIS request be approved. The CS Facilities Committee
will review this matter, among others, on January 20 at 1:30pm in Jacks
room 352.
Les Earnest
∂15-Jan-88 1241 barwise@alan.stanford.edu keeping ssp students posted
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 15 Jan 88 12:41:35 PST
Received: from alan.stanford.edu by russell.stanford.edu (3.2/4.7); Fri, 15 Jan 88 12:44:07 PST
Received: by alan.stanford.edu (3.2/4.7); Fri, 15 Jan 88 12:44:58 PST
Date: Fri, 15 Jan 88 12:44:58 PST
From: barwise@alan.stanford.edu (Jon Barwise)
To: ssp-faculty@alan.stanford.edu
Subject: keeping ssp students posted
Please let me, or Dave, or Margie, or the students themselves (thorugh ssp-students)
∂15-Jan-88 1244 barwise@alan.stanford.edu keeping us posted
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 15 Jan 88 12:44:21 PST
Received: from alan.stanford.edu by russell.stanford.edu (3.2/4.7); Fri, 15 Jan 88 12:47:01 PST
Received: from localhost by alan.stanford.edu (3.2/4.7); Fri, 15 Jan 88 12:47:53 PST
To: ssp-faculty@alan.stanford.edu
Subject: keeping us posted
Date: Fri, 15 Jan 88 12:47:52 PST
From: Jon Barwise <barwise@alan.stanford.edu>
Please remember to keep ssp students informed about special classes
and seminars that might interest them. Things often get changed at
the last minute in departments, and there is no way for us to know
unless you tell us. So either send me, or Dave, or Margie, or the
students themselves (ssp-students@csli) a message.
Thanks.
Jon
∂17-Jan-88 1345 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talks
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Jan 88 13:45:07 PST
Date: Sun 17 Jan 88 13:39:31-PST
From: Anil R. Gangolli <GANGOLLI@Sushi.Stanford.EDU>
Subject: Upcoming AFLB Talks
To: aflb.all@Sushi.Stanford.EDU
Office Phone: (415) 723-3605
Message-ID: <12367404058.19.GANGOLLI@Sushi.Stanford.EDU>
PLEASE NOTE:
* We desperately need speakers for this quarter. If you
would like to talk, please contact me: gangolli@SUSHI.STANFORD.EDU
THIS WEEK'S TALK:
21-January-88: Nancy Amato (UC Berkeley)
An O(n↑2 logn) Solution to the
Scientific American Train Problem
The following problem appeared in the "Computer Recreations" column by
A.K. Dewdney in the June 1987 issue of the Scientific American. The
problem has its origins around the turn of the century. In the
October and November issues he discusses some solutions.
There is a train chugging along a straight stretch of track from
station A to station B. The engineer realizes he needs to return to
station A and is not very excited about the prospect of backing the
train all the way. Luckily there is a short spur line off to the right
side of the track. It is just large enough to hold one car and and has
a switch for either direction of track.
The engineer must use this spur line to turn the entire train around.
This entails reversing the ordering of the cars, and the orientation
of each individual car. We count one unit of work as moving one car
one car-length on the track. Dewdney has an O(n↑3) solution, where n
is the number of cars, and he challenges his readers to do better.
We present an O(n↑2 logn) algorithm for solving a variation of this
problem in which all cars are taken to be locomotives, i.e. we have n
self-propelled cars. We then outline a proof that the algorithm can
be simulated by the original single-locomotive train with at most a
constant-factor time loss.
NEXT WEEK:
28-January-1988: Algorithms For Lunch Bunch
Problem Session
Participants are requested to present problems with or without
solutions, or with incomplete solutions for brainstorming, discussion
and solution.
Please contact me (gangolli@sushi.stanford.edu) if you have a problem
whose presentation might require a substantial portion of the meeting
period.
-------
∂17-Jan-88 2235 ARK@sail.stanford.edu EDBT88 Conference Program
Received: from navajo.stanford.edu by SAIL.Stanford.EDU with TCP; 17 Jan 88 22:35:14 PST
Received: from Sail.Stanford.EDU by navajo.stanford.edu with TCP; Sun, 17 Jan 88 22:29:38 PST
Date: 17 Jan 88 0051 PST
From: Arthur Keller <ARK@sail.stanford.edu>
Subject: EDBT88 Conference Program
To: cs545-people@kl.sri.com, kbms-people@score.stanford.edu,
nail@navajo.stanford.edu
Dear Colleague:
Please give to this Advance Program of the EDBT 88 Conference
the maximum distribution. Many thanks and wishes.
Stefano Ceri, Michele Missikoff, Joachim Schmidt
-------------------------------------------------------------------------
INTERNATIONAL CONFERENCE
EXTENDING DATABASE
TECHNOLOGY
March 14-18, 1988
Cini Foundation, Venice, Italy
Organized by: Sponsored by: In cooperation with:
IASI-CNR AFCET ACM
ISDRS-CNR AICA IEEE
INRIA BCS
Politecnico di Milano GI
Universitat Frankfurt ESPRIT
CRAI CNR of Italy
-------------------------------------------------------------------------
CONFERENCE ORGANIZATION
CONFERENCE CHAIRMAN
S. Ceri, Universita' di Modena, Italy
PROGRAM COMMITTEE
Program Committee Chairperson:
J. W. Schmidt, J. W. Goethe Universitat, Frankfurt, FR Germany
Members:
S. Alagic (Yugoslavia), A. Albano (Italy), P. Apers(Netherlands),
M. Atkinson (Great Britain), F. Bancilhon (France), R. Bayer (FR
Germany), G. Beeri (Israel), G. Bracchi (Italy), M. Brodie (USA),
J. Bubenko (Sweden), S. Ceri (Italy), Q.Chen (China), P. Dadam
(F.R. Germany), R. Demolombe (France), D.J. De Witt (USA),
A.Furtado (Brasil), G. Gardarin (France), G. Gottlob (Austria),
L.A. Kalinichenko (USSR) , Y. Kambayashi (Japan), H. Kangassalo
(Finland), M. Missikoff (Italy), J. Mylopoulos (Canada), E.
Neuhold (F.R. Germany), J.M. Nicolas (F.R. Germany), A. Pirotte
(Belgium), A. Reuter (F.R. Germany), G. Schlageter (F.R. Germany)
A. Sernadas (Portugal), A. Solvberg (Norway), N. Spyratos
(France), P. Stocker (G. Britain), K. Subieta (Poland), P.
Thalheim (D.R. Germany), D.C. Tsichritzis (Switzerland) , Y.
Vassiliou (Greece), G. Wiederhold (USA), H. Williams (G. Britain)
C. Zaniolo (USA), C.A. Zehnder (Switzerland).
ORGANIZING COMMITTEE
Chairman:
M. Missikoff, IASI-CNR, Italy
Treasurer:
P. Atzeni, IASI-CNR, Italy
Industrial exhibitions coordinator:
A. D'Atri, Universita' de L' Aquila, Italy
Tutorial coordinator:
F. L. Ricci, IRSDS-CNR, Italy
EEC coordinator:
J. Elmore, Esprit Programme
US coordinator:[B
C. Zaniolo, MCC, USA
Members:
S. Ceri (Italy), H. Eckhardt (FR Germany), G. Gardarin
(France), K.G. Jeffrey (Great Britain), J.W. Schmidt (FR Germany),
G. Turco (Italy).
-------------------------------------------------------------------------
SESSIONS AND TIMETABLE
9.00-10.30 11.00-12.30 14.00-15.30 16.00-17.30
Monday Tutorial 1 (Gallaire)
March 14 Tutorial 2 (Nestor)
Tuesday Tutorial 3 (Batini-Reiner) Tutorial 5 (Bancilhon)
March 15 Tutorial 4 (DeWitt) Tutorial 6 (Bernstein)
-------------------------------------------------------------------------
Wednesday Opening Session 2 Session 3 Session 4
March 16 session Databases and Expert System Distributed
Logic Approaches to Databases and
Databases Transactions
Management
Thursday Session 5 Session 6 Project Session Project Session
March 17 Database Complex 7a: Support for 8a: Distributed
Administration Database Data and Database
Objects Knowledge-Based Applications
Applications
--------------------------------
Session 7b Session 8b
Efficient Data Efficient Data
Access 1 Access 2
Friday Session 9 Session 10 Panel Session 11 Session 12
March 18 Efficiency by Data Types Databases and Special Data
Replicated and Data Programing
Data Semantics Languages:
(inv. speaker: a Shut-Gun
L. Cardelli) Marriage
A TECHNICAL EXHIBITION will be open from Monday 14th to Friday 18th.
-------------------------------------------------------------------------
SOCIAL PROGRAM
Welcome Reception (Wednesday, March 16, 19:00).
Light Dinner and Baroque Concert (Thursday, March 17, 19:00).
Wine on the Laguna (Friday, March 18, 20:30).
-------------------------------------------------------------------------
TUTORIALS
Monday, March 14, 14.00 - 17.30
Tutorial N. 1: Logic and Databases
H. Gallaire, ECRC, FR Germany.
Tutorial N. 2: Database Technology for Software Engineering
J. Nestor, Carnegie Mellon University, USA.
Tuesday, March 15, 9.00 - 12.30
Tutorial N. 3: Database Design: Methodologies and Automated Tools
C. Batini, Universita' di Roma "La Sapienza", Italy.
D. Reiner, Lotus Development Corporation, USA.
Tutorial N. 4: Extensible Database Systems
D. J. De Witt, University of Wisconsin, USA.
Tuesday, March 15, 14.00 - 18.00
Tutorial N. 5: Object-Oriented Databases
F. Bancilhon, IN2, France.
Tutorial N. 6: Transaction Processing Systems
P. Bernstein, Digital Corporation, USA.
Detailed information about the Tutorials' content can be obtained
from:
F. L. Ricci
Tutorial coordinator
IRSDS - CNR
Via C. De Lollis 12
00185 Rome, Italy
ph. (39-6) 495-2351
-------------------------------------------------------------------------
REGISTRATION
Registration fee is in Italian lira; for participants'
convenience we add in parentesis the approximate prices in dollar
at the exchange rates of Lit. 1250 for 1 US $ (as of December
1987). Reduced fees apply to affiliates of: AICA, GI, BCS, AFCET,
ACM, IEEE.
Conference fee: before Febr. 15
full: Lit. 430.000 (US $ 350)
reduced: Lit. 360.000 (US $ 290)
after Febr. 15
full: Lit. 570.000 (US $ 455)
reduced: Lit. 485.000 (US $ 390)
Conference registration fee includes: the Conference Proceedings,
access to the Conference Exhibition, three lunches offered at the
Conference location on S. Giorgio Island, the participation to
the Welcome Reception and to the Wine on the Laguna events, and
the coffee breaks. The Light Dinner and Baroque Concert on
Thursday night require a separate ticket of Lit. 30.000 (US $
24).
Fee for the participation to one tutorial:
before Febr. 15
full: Lit. 200.000 (US $ 160)
reduced: Lit. 170.000 (US $ 135)
after Febr. 15
full: Lit. 240.000 (US $ 190)
reduced: Lit. 200.000 (US $ 160)
Tutorial registration fee includes the technical material and a
coffee break. On Tuesday 15th a restaurant service will be
available on-site (lunch ticket: Lit. 30.000).
-------------------------------------------------------------------------
HOW TO REGISTER
Advance registrations should be made by filling the registration
form and mailing it before February 15 to:
EDBT 88
IASI
Viale Manzoni 30
00185 ROMA - ITALY
Payments should be made with an international draft payable to:
CERIAS-EDBT or, alternatively, with an international money order
to:
CERIAS-EDBT
bank account 4585
c/o Banca Popolare di Bergamo
Agenzia Citta' Alta
24100 Bergamo, Italy
In case of international money order, please enclose a copy of
the money order with the registration form.
ON-SITE REGISTRATION will be accepted with international drafts
or cash at the Conference desk. The Conference desk will be open
from Monday 14 to Friday 18, from 8:30 am to 5:30 pm.
-------------------------------------------------------------------------
ACCOMMODATION
Accommodation for conference participants is available in four
hotel categories (see Hotel Reservation Form). Hotel Reservation
Form should be mailed to:
American Express CO SpA
BMC ITALY
Piazza di Spagna, 38
00187 Roma (Italy)
-------------------------------------------------------------------------
CONTACT ADDRESS
More information and a full printed copy of the Program can be
obtained from:
Michele Missikoff Carlo Zaniolo
IASI-CNR MCC
Viale Manzoni 30 3500 West Balcones Center Drive
00185 Roma Austin, TX 78759-6509
Italy USA
ph. (39-6) 770031 ph. (512)-343-0978
e-mail: Missikoff@iasi.cnr.osiride.ean
More information about the Technical Exibition can be obtained
from:
Alessandro D'Atri
Dip. Ingegneria Elettrica
Universita' dell'Aquila
Localita' Monteluco
67100 L'Aquila, Italy
e-mail (uucp): i2unix!disrm!datri
telex: AQUING I 601156
-------------------------------------------------------------------------
REGISTRATION FORM
NAME.................................
First Name...........................
Affiliation..........................
Address.............................. City....................
Country.............................. Post Code...............
Tel. ................................ Telex...................
Registration fees
Amount
Conference: before Febr. 15
full: Lit. 430.000 .......
reduced: Lit. 360.000 .......
after Febr. 15
full: Lit. 570.000 .......
reduced: Lit. 485.000 .......
Tutorials: fee for one tutorial
before Febr. 15
full: Lit. 200.000 .......
reduced: Lit. 170.000 .......
after Febr. 15
full: Lit. 240.000 .......
reduced: Lit. 200.000 .......
Please mark the tutorial(s) you wish to register for:
Tutorial 1 [] Tutorial 3 [] Tutorial 5 []
Tutorial 2 [] Tutorial 4 [] Tutorial 6 []
Baroque Concert with Dinner: Lit. 30.000 .......
TOTAL .......
PAYMENT
[] I enclose an international draft for the amount
indicated in the total.
[] I enclose the photocopy of the money order to
CERIAS-EDBT, bank account #4585, Banca Popolare di Bergamo
Agenzia Citta' Alta, 24100 Bergamo, Italy.
-------------------------------------------------------------------------
HOTEL RESERVATION FORM
Last Name............................
First Name...........................
Address.............................. City....................
Country.............................. Post Code...............
Tel. ................................ Telex...................
Name(s) of accompaning person(s):.............................
HOTEL ACCOMODATION: HOTEL CATEGORY: o Superior First Class
Nr .... Single Rooms o First Class
Nr .... Double Rooms o Second Class
From ........... To ........... o Economy
HOTEL RATES:
Superior First double room: Lit. 230.000
single room: Lit. 140.000
First class double room: Lit. 140.000
single room: Lit. 90.000
Second class double room: Lit. 110.000
single room: Lit. 70.000
Economy double room: Lit. 90.000
single room: Lit. 50.000
The above are daily rates, including breakfast and taxes. Enclose
payment for the first night + Lit. 10.000 as agent fee. Please
make your payment using:
o International Draft Nr..................................
o Personal Cheque Nr......................................
o American Express Card Nr. .......................
Expiration Date .................
Date .............. Signature ..........................
f
∂18-Jan-88 1116 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu [nilsson: Tuesday Lunch]
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 88 11:16:46 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 18 Jan 88 11:11:31-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA16012; Mon, 18 Jan 88 11:15:22 PST
Date: Mon, 18 Jan 88 11:15:22 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8801181915.AA16012@Tenaya.stanford.edu>
To: faculty@score
Subject: [nilsson: Tuesday Lunch]
Return-Path: <nilsson>
Date: Mon, 18 Jan 88 11:05:56 PST
From: nilsson (Nils Nilsson)
To: faculty
Subject: Tuesday Lunch
The Faculty Lunch this Tuesday (Jan. 19) will be in ERL 442.
NOTE CHANGE OF SITE FOR THIS LUNCH!
Carolyn Tajnai will bring us up to date on Forum Activities.
-Nils
∂18-Jan-88 1626 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Minilabs
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 88 16:26:32 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 18 Jan 88 16:21:18-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA16430; Mon, 18 Jan 88 16:25:11 PST
Date: Mon, 18 Jan 88 16:25:11 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8801190025.AA16430@Tenaya.stanford.edu>
To: faculty@score
Subject: Minilabs
MINILABS IN THE EXEDRA
Jim Gibbons has proposed (and I have supported) an idea to help fund
our new buildings. The idea is to invite, say, five companies to
send, say, five each researchers to live with us in the exedra
buildings and participate with us and with our students in mutually
agreeable research projects. Although we do not have University
approval for the idea, it has been informally discussed with Don
Kennedy and Jim Rosse and a few prospects just to see if it is worth
considering in more detail. Hewlett Packard seems very excited about
it, so now we have to determine, first, whether we, as CSD/CSL
faculty, are in favor of it, and next, whether the University
approves.
Here are the details and conditions that we have been assuming all
along and which, it seems, would have to be observed in order to make
the idea work:
1) Each minilab would be co-led by a faculty host and a company
project leader. The establishment of a minilab will depend on being
able to find an appropriate and eager faculty host. The "project" to
be undertaken by the minilab would be one which the faculty member
would be wanting to work on anyway and one for which s/he is receiving
(or would be receiving) other research support. The project would be
mutually agreed on by the faculty host and by the company project
leader.
2) All visitors to a minilab would have to be approved by their
faculty host. It is to be expected that faculty would not want to
have anyone as visitors who fail to meet the standards of excellence
set by the faculty host.
3) A minilab agreement would be for five years and would involve a
gift to Stanford of $5M ($1M each year)---assuming five company people
in a lab.
4) Minilab gifts would be used, first, to compensate Stanford for the
real costs of having visitors (space, support, ...). Although we
haven't done all the arithmetic yet, probably about half of the $5M
would be allocated to these costs. The other half would be put in a
special fund to help pay for the new buildings. (Some of the support
costs would help amortize the construction costs, and these
complications would be taken into account.)
5) None of the $5M would be used to support actual Stanford research
costs (faculty salaries, student RA-ships, research equipment, etc.)
If a minilab company wanted to enter into an additional agreement with
Stanford PIs to support research, that's fine, but it's outside the
scope of the minilab idea. (The minilab idea being to raise money for
the new buildings.)
6) Minilab companies would pay the salaries of their employees
(including any support staff---counted among the five people). They
would also pay for any computer or other equipment which they would
use in the minilab.
7) The usual Stanford rules regarding rights, inventions, publications,
etc. would apply.
I have supported this idea because I think we often work with Research
Associates anyway, and we would expect that the people sent by the
companies would be of Research Associate quality. (We should accept
no less.) Also it's a good way to raise a substantial portion of the
funds needed for the new building. Also it allows us to build and
claim the extra space we'll eventually need even if we don't need it
right away when we move into the new buildings. We can cancel the
minilab agreements after the first five-year term and reclaim the
space for other uses. (I have figured 10,000 net square feet into the
new buildings for the space needed by the company representatives of
the five minilabs---2,000 nsf per lab.)
It is important to note that the Provost/President have not approved
this idea. It does complicate the Centennial fund-raising
campaign---designed as it is to encourage general purpose gifts. They
must also be assured that the space used by the minilabs would ultimately
be needed for purely Stanford purposes.
I would like to get from you the following information:
1) Do you think the idea is worth pursuing at all (possibly with
extra or different conditions that you will tell me about)?
2) Would you, yourself, be interested in being a faculty host, given
appropriate circumstances (which you will eventually tell me about)?
3) Do you see other advantages or pitfalls that we should be taking
into account now?
-Nils
∂18-Jan-88 1636 GENESERETH@Score.Stanford.EDU Re: Minilabs
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 88 16:36:25 PST
Date: Mon 18 Jan 88 16:31:17-PST
From: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Subject: Re: Minilabs
To: nilsson@Tenaya.Stanford.EDU
cc: faculty@Score.Stanford.EDU
In-Reply-To: <8801190025.AA16430@Tenaya.stanford.edu>
Message-ID: <12367697470.28.GENESERETH@Score.Stanford.EDU>
Nils
Well it is an intriguing idea, but it worries me in two practical ways.
(1) The incentive to be a faculty host is not clear. Sure we all need
to be good citizens and help out the department, the school, and th e
university; but we don't alwasys have time for this, given the need
to get funding for ourselves and our students and the desire to do
good research rather than holding the hands of our visitors. Sure,
they could help out. I have a good visitor from NEC right now. But
I know that othjer faculty members in tha past have had bad experiences
with visitors, even those they approved. The problem is compounded by
the fact that companies often put pressure on their employees to do
specific tasks, whihc may make even the good ones less than useful.
(2) The minilan idea might affect mor ethan the centennial campaign.
It might make some companies less willing to fund research directly.
I suggest a revision in whihc the faculty hosts get some incentive payment
for hosting these visitors in terms of personnel support.
mrg
-------
∂18-Jan-88 2100 REGES@Score.Stanford.EDU switching to Polya
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 88 21:00:21 PST
Date: Mon 18 Jan 88 20:53:41-PST
From: Stuart Reges <REGES@Score.Stanford.EDU>
Subject: switching to Polya
To: ac@Score.Stanford.EDU
cc: ball@Score.Stanford.EDU, tom@Score.Stanford.EDU,
gotelli@Score.Stanford.EDU, bureaucrats@Score.Stanford.EDU
Office: CS-TAC 22, 723-9798
Message-ID: <12367745240.12.REGES@Score.Stanford.EDU>
As most of you probably know, we will soon move students from SUSHI to POLYA
(our new VAX 8700). This move reopens many issues that we haven't had to deal
with for a long time. A small group is holding meetings to plan the
transition. There is one particular point that we would like to get "concept
approval" on before we proceed.
If we give students unlimited accounts on POLYA, they might quickly drive the
department into financial ruin. We plan to encourage students to make use of
PORTIA to complete coursework and to use POLYA only for extra things that LOTS
does not provide. Even so, we almost certainly need to limit student accounts.
We are talking about giving our MS students something like $75/month to spend
on the machine. We would like to give the PhD students unlimited accounts, but
we are nervous about how much they might spend. Those of you who have been
around for a while will remember a policy that Jeff Ullman wrote that stated
that PI's would pay for PhD students' computer usage and that the department
would serve only as sponsor of last resort. Our working group suggests that we
resurrect that policy. We would give PhD students unlimited accounts, but we
would, whenever possible, charge the usage to a research project. Only truly
unsupported students (e.g., first-year students) would be picked up by the
department.
The basic question, then, is whether you agree that you can cover the cost of
unlimited POLYA accounts for those PHD students affiliated with your project
(i.e., those on RA support and those fellowship holders working with you). If
you have a strong objection, please let me know as soon as possible.
-------
∂19-Jan-88 0117 FACIL-mailer more on POLYA
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jan 88 01:14:37 PST
Date: Tue 19 Jan 88 01:10:29-PST
From: Stuart Reges <REGES@Score.Stanford.EDU>
Subject: more on POLYA
To: bureaucrats@Score.Stanford.EDU, facil@Sail.Stanford.EDU
Office: CS-TAC 22, 723-9798
Message-ID: <12367791987.11.REGES@Score.Stanford.EDU>
I think it is premature to ask the student body at large for input, but we do
need to start thinking about how to get student input and how to evolve a
reasonable set of policies for POLYA. The small group that I mentioned is
composed mostly of CSD administrators who want to make sure that the department
doesn't go bankrupt and CSD-CF staff who are, naturally, curious about how to
set up POLYA. We have scheduled another meeting for this Thursday from 3-4 (I
believe in MJH 252). I know that the student bureaucrats have been invited.
Members of the Facilities Committee are certainly welcome. If there are others
who really should be there for some reason, I don't think anyone will object.
I am just trying to avoid a public debate on bboard about policies that haven't
yet been formulated. Let's have debate, but after we've had a bit more time to
think things through.
-------
∂19-Jan-88 0609 @Score.Stanford.EDU,@score.stanford.edu:cheriton@Pescadero.stanford.edu Re: switching to Polya
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jan 88 06:09:04 PST
Received: from Pescadero by SCORE.STANFORD.EDU with TCP; Tue 19 Jan 88 06:04:45-PST
Received: by Pescadero from Score.Stanford.EDU (5.54/Ultrix2.0-B)
id AA00203; Tue, 19 Jan 88 06:08:40 PST
Received: from Pescadero by SCORE.STANFORD.EDU with TCP; Tue 19 Jan 88 06:04:15-PST
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA00590; Tue, 19 Jan 88 00:17:38 PST
Date: Tue, 19 Jan 88 00:17:38 PST
From: "David Cheriton" <cheriton@pescadero.stanford.edu>
Message-Id: <8801190817.AA00590@Pescadero>
To: REGES@score.stanford.edu, ac@score.stanford.edu
Subject: Re: switching to Polya
Cc: ball@score.stanford.edu, bureaucrats@score.stanford.edu,
gotelli@score.stanford.edu, tom@score.stanford.edu
Regarding "unlimited accounts", I need to check with my research sponsors
to see if they will approve unlimited funds for me first. More seriously,
I think the policy you cite is totally inappropriate. I am willing to pay
for the computing that my RAs do as part of carrying out the tasks that I
assign them for their RAship and only on the machines that I designate.
I believe that that is, according to my contracts, all I am allowed to
provide.
I propose that all Ph.D. students be allotted the same dollar limit
per month and any student can get that upped by coming up with a sponsor.
I think research projects (such as mine) will (continue to) help the dept.
by providing other computing facilities to their RAs such that many students
will not even use their minimum Polya allotment.
David Cheriton
∂19-Jan-88 0638 @Score.Stanford.EDU:cheriton@Pescadero.stanford.edu Re: Minilabs
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jan 88 06:38:51 PST
Received: from Pescadero by SCORE.STANFORD.EDU with TCP; Tue 19 Jan 88 06:33:56-PST
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA00687; Tue, 19 Jan 88 00:32:40 PST
Date: Tue, 19 Jan 88 00:32:40 PST
From: "David Cheriton" <cheriton@Pescadero.stanford.edu>
Message-Id: <8801190832.AA00687@Pescadero>
To: faculty@score.stanford.edu, nilsson@tenaya.stanford.edu
Subject: Re: Minilabs
I agree with Mike. Interesting idea but it seems weak as stated in terms
of motivation for a faculty host. Instead of offering money as an incentive
(or perhaps as well as) one might consider making such hosting equivalent
of a course per year, so one could teach one fewer courses while hosting
at no extra research offset. Also, one might consider providing extra
people and equipment space for the faculty host, given that such a minilab
is going to generally want a supporting cast or be affiliated with a group
that will need extra because of the minilab.
Frankly, I dont see there being any real danger, especially in the long
run, in losing research funding because of minilabs. Also, I would expect
that a minilab might bring in $5 from someone who would otherwise give
$.50 or nothing, so the competition with the cent. campaign would be minimal.
(But these are unsupported guesses, speculations.)
David Cheriton
∂19-Jan-88 0949 GENESERETH@Score.Stanford.EDU Re: switching to Polya
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jan 88 09:49:38 PST
Date: Tue 19 Jan 88 09:44:48-PST
From: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Subject: Re: switching to Polya
To: cheriton@Pescadero.Stanford.EDU
cc: REGES@Score.Stanford.EDU, ac@Score.Stanford.EDU, ball@Score.Stanford.EDU,
bureaucrats@Score.Stanford.EDU, gotelli@Score.Stanford.EDU,
tom@Score.Stanford.EDU
In-Reply-To: <8801190817.AA00590@Pescadero>
Message-ID: <12367885618.41.GENESERETH@Score.Stanford.EDU>
David said it exactly right. I completely agree. Everyone gets the
same basic allotment; those with sponsors get more.
mrg
-------
∂19-Jan-88 1003 FACIL-mailer RE: more on POLYA
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jan 88 10:03:10 PST
Date: Tue 19 Jan 88 09:58:43-PST
From: Raul Duran <DURAN@Sushi.Stanford.EDU>
Subject: RE: more on POLYA
To: reges@Score.Stanford.EDU
cc: facil@Sail.Stanford.EDU, bureaucrats@Sushi.Stanford.EDU
Message-ID: <12367888149.39.DURAN@Sushi.Stanford.EDU>
You have a good point Stuart. At least one of the student bureaucrats
will attend. The general student meeting will be next Tuesday Jan 26,
so that may be a good time to introduce the students at large regarding
any policies which may be formulated on Thursday.
-- Bureaucrats.
-------
∂19-Jan-88 1405 @Score.Stanford.EDU:FEIGENBAUM@SUMEX-AIM.Stanford.EDU Re: switching to Polya
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jan 88 14:05:37 PST
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 19 Jan 88 13:59:23-PST
Date: Tue, 19 Jan 88 14:01:43 PST
From: Edward Feigenbaum <FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
Subject: Re: switching to Polya
To: GENESERETH@Score.Stanford.EDU, cheriton@Pescadero.Stanford.EDU
cc: REGES@Score.Stanford.EDU, ac@Score.Stanford.EDU, ball@Score.Stanford.EDU,
bureaucrats@Score.Stanford.EDU, gotelli@Score.Stanford.EDU,
tom@Score.Stanford.EDU
In-Reply-To: <12367885618.41.GENESERETH@Score.Stanford.EDU>
Message-ID: <12367932387.98.FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
Dave Cheriton's view is completely coincident with mine.....Ed
-------
∂19-Jan-88 1536 RICHARDSON@Score.Stanford.EDU Opportunity for research funding in computer science
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jan 88 15:36:47 PST
Date: Tue 19 Jan 88 15:20:38-PST
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: Opportunity for research funding in computer science
To: faculty@Score.Stanford.EDU
Message-ID: <12367946754.15.RICHARDSON@Score.Stanford.EDU>
This is to announce that there is a bulletin from the Universities Space
Research Association regarding opportunities for research funding in
computer science. Sponsorship is through the NASA-sponsored institute,
the Center of Excellence in Space Date and Information Sciences (CESDIS).
Please drop by room 214, Margaret Jacks Hall, for more information. Thank
you,
Heidi Schubert
-------
∂20-Jan-88 1819 emma@alan.stanford.edu CSLI Calendar, January 21, 3:14
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 20 Jan 88 18:19:49 PST
Received: from alan.stanford.edu by russell.stanford.edu (3.2/4.7); Wed, 20 Jan 88 17:34:12 PST
Received: by alan.stanford.edu (3.2/4.7); Wed, 20 Jan 88 17:35:07 PST
Date: Wed, 20 Jan 88 17:35:07 PST
From: emma@alan.stanford.edu (Emma Pease)
To: friends@alan.stanford.edu
Subject: CSLI Calendar, January 21, 3:14
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
21 January 1988 Stanford Vol. 3, No. 14
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 21 January 1988
2:15 p.m. CSLI Seminar
Room G-19 Factorization in Grammar:
Redwood Hall What we can learn about grammar design from Chichewa
Joan Bresnan
(bresnan@csli.stanford.edu)
Abstract in last week's Calendar
3:30 p.m. Tea
Ventura Hall
--------------
CSLI ACTIVITIES FOR NEXT THURSDAY, 28 January 1988
12 noon TINLunch
Ventura Hall Reading: "True Believers: The Intentional
Conference Room Strategy and Why it Works"
by Daniel Dennett
Discussion led by Adrian Cussins
(cussins.pa@xerox.com)
Abstract below
2:15 p.m. CSLI Seminar
Room G-19 Modal Subordination, Situations, and Reference Time
Redwood Hall Craige Roberts
(croberts@csli.stanford.edu)
Abstract below
3:30 p.m. Tea
Ventura Hall
--------------
NEXT WEEK'S TINLUNCH
Reading: "True Believers: The Intentional Strategy and Why it Works"
by Daniel Dennett
In D. Dennett, The Intentional Stance, chapter 2,
Bradford Books, 1987. Also in A. F. Heath, ed., Scientific
Explanation, Oxford University Press, 1981.
Discussion led by Adrian Cussins
(cussins.pa@xerox.com)
January 28
Dennett's article "True Believers" is, as he says, the flagship
expression of his theory of the intentional stance replacing his 1971
article "Intentional Systems." It seems to me that the theory should
be discussed around CSLI since there appear to be many commonalities
between his position and the Barwise/Perry/Israel attitude to
psychology. For example (and a little flippantly): there is no
qualitative difference between people and frogs; there is no such
thing as intrinsic intentionality; the language of thought is false;
the notion of representation is not primary in psychological theory;
psychological properties are not natural kinds. I will briefly
introduce Dennett's theory for those not familiar with it, and raise
one or two objections. I think that what Dennett is really saying is
that there can be no such thing as The Science of the Mind, or, in
other words, that the best a psychologist can hope for is to be a
hacker. Now, if CSLI shares this view it might explain a lot ...
--------------
NEXT WEEK'S SEMINAR
Modal Subordination, Situations, and Reference Time
Craige Roberts
(croberts@csli.stanford.edu)
January 28
The phenomenon of modal subordination involves the apparent extension
of the scope of modal operators intersententially across segments of a
discourse. This presents problems both for the analysis of the
logical entailments of individual sentences in such contexts, and for
theories of anaphora in discourse. In earlier work, I proposed an
account of modal subordination which involved extending discourse
representation theory to include modal operators. In this talk I will
briefly review that proposal and present recent work that attempts to
address two unresolved problems: the existence of similar examples,
which involve non-modal operators, such as temporal operators and
adverbs of quantification, and a restriction on the interpretation of
tenses in modal subordination contexts. I will suggest that these
problems may be resolved by taking modal operators to range over
situations (whether the situations of situation semantics, or the
partial worlds situations recently proposed by Angelika Kratzer), and
by taking temporal units to be defined in terms of primitively ordered
events (themselves a type of situation). I will present a theory of
the interpretation of discourse representations, which implements
these ideas in a possible-worlds semantics.
∂20-Jan-88 1942 FACIL-mailer Minutes of Facilities Committee meeting of 1/20/87
To: facil@SAIL.Stanford.EDU, Nilsson@SCORE.STANFORD.EDU,
Reges@SCORE.STANFORD.EDU, BScott@SCORE.STANFORD.EDU, AG@AMADEUS.STANFORD.EDU,
MAYR@SCORE.STANFORD.EDU, oliger@NAVAJO.Stanford.EDU
From: Les Earnest <LES@SAIL.Stanford.EDU>
BRAQUE. The Committee agrees with the proposal to transfer the Ncube
computer (Braque) to Anoop Gupta's group in CIS with the understanding
that they will make it work with ethernet and will make the system
available to other groups on a cost-sharing basis.
APS TYPESETTER. Income from the APS typesetter is about half of the
expense. We could raise the rates, but that would make it non-competitive
with outside services. Alternatively, we could advertise within Stanford
and possibly drum up some more business. The consensus was in favor of
trying to sell it to another group within Stanford, such as GSB or the
Data Center (remnant of ITS). Failing that, perhaps it should be sold
outside. Jim Ball will look into these possibilities.
BELL & HOWELL SLIDEMAKER. CSD administration appears reluctant to have
CSD-CF invest the $4k or so that would be required to get a PC capable of
driving the slidemaker, which makes 35 mm. color slides. One possibility
would be to give it to a group in the department or, failing that, to an
outside group that wants it, such as Statistics. Les Earnest will send
Jim Ball a list of CSD people who had originally said they wanted it. Jim
will review this matter and recommend a course of action.
POLYA. Polya, the new VAX 8700, will support charge-limiting of users.
Consensus view was that all Masters and PhD students should be provided
with accounts on Polya with fairly low charge limits -- Stuart Reges
suggests $75/month. Students will be expected to do their classwork on
Portia or other AIR computers. Certain individuals, such as PhD students
doing unsponsored research, would be given higher limits on Polya, as
will those on sponsored research projects whose PIs underwrite their
accounts. Stuart also plans to support Polya accounts for CS
undergraduates at some level.
PRINTING FROM PORTIA. CSD is paying the bills for local print jobs that
come from Portia, though there is no individual accounting. If Portia
accounts of CS people were controlled, it would be possible to do accounting
on this printing and charge it to individual CSD-CF accounts. The Committee
recommends that this be done.
Les Earnest
CS Facilities Chair
∂20-Jan-88 2042 REGES@Score.Stanford.EDU Another POLYA proposal
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Jan 88 20:42:01 PST
Date: Wed 20 Jan 88 20:36:58-PST
From: Stuart Reges <REGES@Score.Stanford.EDU>
Subject: Another POLYA proposal
To: ac@Score.Stanford.EDU
cc: ball@Score.Stanford.EDU, gotelli@Score.Stanford.EDU,
tom@Score.Stanford.EDU, bureaucrats@Score.Stanford.EDU,
jwilson@Score.Stanford.EDU
Office: CS-TAC 22, 723-9798
Message-ID: <12368266484.34.REGES@Score.Stanford.EDU>
The many messages that I received about POLYA have been helpful. The plan
that I mentioned last week is obviously not going to work. Let me try one
other idea.
The Facilities Committee met today and there was a strong sentiment expressed
that we should have a POLYA account for every student in the department, to
carry over the SUSHI psychology of having a CSD-operated machine where all
students have an account. The discussion currently is heading towards a plan
where all students would be charge-limited to the same rather moderate monthly
rate. I have suggested $75/month, but the exact number is still under
discussion.
I suggest that we create minimal accounts for all students, but that PIs pay
for students affiliated with their projects. The argument in favor of this
approach is that research projects should provide an umbrella of support for
the education of students affiliated with the project. I believe this is the
spirit of the Ullman computer usage policy that we passed several years ago.
This gives PIs the freedom to increase the POLYA allocation or keep it low and
have their students work on other machines. The charge limit should protect
PIs from runaway bills.
Again, please send objections to me (and to the whole list if you feel it
appropriate).
-------
∂20-Jan-88 2330 LOGMTC-request Logic Seminar
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 20 Jan 88 23:30:37 PST
Received: by russell.stanford.edu (3.2/4.7); Wed, 20 Jan 88 23:33:47 PST
Date: Wed 20 Jan 88 23:33:46-PST
From: Sol Feferman <SF@Russell.Stanford.EDU>
Subject: Logic Seminar
To: logic@russell.stanford.edu
Message-Id: <569748826.0.SF@Russell.Stanford.EDU>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@Russell.Stanford.EDU>
Speaker: Prof. Vaughan Pratt, Computer Science Dept. , Stanford
Title: Dynamic types: unifying types and concurrency.
Time: Tuesay, Jan. 26, 4:15-5:30
Place: Room 381T, Math Corner, Stanford
S. Feferman
Abstract:
Dynamic types is a system of arithmetic whose values are interpretable
both as types and concurrent behaviors. This unification of types and
concurrency also extends both: the usual arithmetic of type
constructors becomes the fine stage of a useful coarse-fine distinction
in type construction, while the notion of time as a partial order is
uniformly extended to other notions of time including real time,
interval time, stochastic time, etc. The formal basis for the approach
is an extension of enriched category theory enriching not just homsets
but objects.
V. Pratt
-------
∂20-Jan-88 2348 @Score.Stanford.EDU:cheriton@Pescadero.stanford.edu Re: Another POLYA proposal
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Jan 88 23:48:39 PST
Received: from Pescadero by SCORE.STANFORD.EDU with TCP; Wed 20 Jan 88 23:43:29-PST
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA08693; Wed, 20 Jan 88 23:47:16 PST
Date: Wed, 20 Jan 88 23:47:16 PST
From: "David Cheriton" <cheriton@pescadero.stanford.edu>
Message-Id: <8801210747.AA08693@Pescadero>
To: REGES@score.stanford.edu, ac@score.stanford.edu
Subject: Re: Another POLYA proposal
Cc: ball@score.stanford.edu, bureaucrats@score.stanford.edu,
gotelli@score.stanford.edu, jwilson@score.stanford.edu,
tom@score.stanford.edu
Stuart, with all due respect, I think you need to do some research into
the research contracts and grants we have in this department before making
such a proposal. There is no way that "research projects should provide
an umbrella of support for students affiliated with the project" unless
our sponsors are anxious to do this and provide for it both in the contract
language as well as funding. Moreover, I think the more appropriate view is
for the department to be pleased and supportive the larger educational
opportunities that research projects make available to the students.
In general, I think the embedded view of the research projects as fat cats
taking advantage of the department is false and is going to have to change.
Within my project, the number of CS students I am supporting has decreased
significantly in favor of EE students and staff. I think the dept. should
more concerned about reversing this trend (especially if it is as widespread
as I think) than increasing the disadvantages of hiring a CS students.
David Cheriton
∂21-Jan-88 0828 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: Another POLYA proposal
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Jan 88 08:27:54 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 21 Jan 88 08:21:58-PST
Date: 21 Jan 88 0825 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: Another POLYA proposal
To: ac@SCORE.Stanford.EDU, REGES@SCORE.Stanford.EDU, ball@SCORE.Stanford.EDU,
bureaucrats@SCORE.Stanford.EDU, gotelli@SCORE.Stanford.EDU,
jwilson@SCORE.Stanford.EDU, tom@SCORE.Stanford.EDU,
ARK@SAIL.Stanford.EDU
Jeff Ullman's policy made sense in a department that had most computer
equipment controlled by CSD-CF. In a department with a lot of computers
controlled by individual PIs, it is less applicable. Furthermore, the
existence of Sushi for over 2 years has changed our perceptions to make
that policy inappropriate.
First, there is nothing special about the cycles on Polya. It's a Unix
machine and there are many like it. The software that runs on it can be
made to run on practically any VAX. The data on it can easily be
transferred to other VAXen.
PI's should not be required to pay for Polya just because it exists and is
the departmental machine.
Here's my proposal:
1. CS PhD and CS MS students, CS PhD alumni, and other eligible classes
of students are eligible for accounts on Polya.
2. Any one in Point 1 who does not otherwise have a sponsored account on
Polya will get a (charge-limited) account sponsored by the department.
The department is not obligated to pay any Polya charges for someone
who also has a sponsored account on Polya.
3. A PI (or other suitable entity controlling an budget account)
completely paying for a computer account may request a budget limit for
that account, although the actual charge may exceed this amount because on
printing and disk space overruns that were not accounted for. A
collection of PIs, etc., may also make this request if they combined
completely pay for an account on any particular CSD-CF computer.
Of course, this includes department-sponsored accounts.
4. The department may provide consistent budget limits for people in
Point 2 based on the category in Point 1. The amounts for the categories
are subject to faculty approval. The amounts may be increased on an
individual basis by the Chairman or his designee.
Arthur
∂21-Jan-88 1043 LOGMTC-mailer Logic-of-Programs Seminar
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Jan 88 10:42:30 PST
Date: Thu 21 Jan 88 10:35:23-PST
From: Thomas Henzinger <HENZINGER@Sushi.Stanford.EDU>
Subject: Logic-of-Programs Seminar
To: LOP: ;
cc: csd@Sushi.Stanford.EDU, logmtc@Sail.Stanford.EDU
Message-ID: <12368419114.32.HENZINGER@Sushi.Stanford.EDU>
*************************************
* LOGIC OF PROGRAMS [LOP] Seminar *
*************************************
Fridays 11:30-12:30, MJH 301
January 22: Prof. Vaughan Pratt (Stanford Univ.),
"An Introduction to Dynamic Logic"
January 29: Dr. Leslie Lamport (DEC-SRC),
"What Good is Temporal Logic?"
Upcoming talks this quarter by John Mitchell, Joe Halpern, Luca Cardelli,
Joseph Goguen, Phokion Kolaitis, and Zohar Manna.
-------
∂21-Jan-88 1325 ULLMAN@Score.Stanford.EDU POLYA accounts
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Jan 88 13:25:27 PST
Date: Thu 21 Jan 88 13:20:37-PST
From: Jeffrey D. Ullman <ULLMAN@Score.Stanford.EDU>
Subject: POLYA accounts
To: reges@Score.Stanford.EDU, ac@Score.Stanford.EDU, ball@Score.Stanford.EDU,
bureaucrats@Score.Stanford.EDU, gotelli@Score.Stanford.EDU,
jwilson@Score.Stanford.EDU, tom@Score.Stanford.EDU
Message-ID: <12368449192.11.ULLMAN@Score.Stanford.EDU>
I think my original plan was developed at a time when NO academic
computing was done on CSD machines.
Thus, the contracts and grants were expected to pay for research
use, and the usual electronic mail and such that goes along with
such accounts (I think funding agents accept the premise that
they are supporting incidental flamage, etc, as long as it
represents a SMALL proportion of the total computing).
We are now in a very different situtation, and I think David is correct
that we must abandon the idea of trying to load contracts with
a significant amount of computing that is not directly attributable
to the research being funded.
---jeff
-------
∂21-Jan-88 1359 TAJNAI@Score.Stanford.EDU SUNRISE CLUB MEETS TUESDAY, JANUARY 26]
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Jan 88 13:59:11 PST
Date: Thu 21 Jan 88 13:51:28-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: SUNRISE CLUB MEETS TUESDAY, JANUARY 26]
To: faculty@Score.Stanford.EDU, phd@Score.Stanford.EDU,
csl-students@Sierra.Stanford.EDU
Message-ID: <12368454809.11.TAJNAI@Score.Stanford.EDU>
This is a reminder. If you have not RSVP'd, and if you plan to
attend, please let me know.
Date: Thu 21 Jan 88 09:05:50-PST
From: Joanne Chequer <CHEQUER@Sierra.Stanford.EDU>
Subject: SUNRISE CLUB MEETS TUESDAY, JANUARY 26
Ladies and Gentlemen:
The Sunrise Club will meet again on Tuesday, January 26 at 7:30 a.m.
in the Oak Lounge West, Tresidder Union. You are invited!
Professor John Cioffi of the Information Systems Laboratory,
Electrical Engineering, will speak on "Storage Channel Equalization:
A Signal Processing Means by Which to Increase Density in Commercial
Disk Storage Systems."
Breakfast will be served, so I'd appreciate your R.S.V.P.
Please reply to me at CHEQUER@SIERRA or call 3-9042. Thanks, and
hope to see you there.
Joanne
-------
-------
∂21-Jan-88 1548 FACIL-mailer Re: Minutes of Facilities Committee meeting of 1/20/87
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Jan 88 15:48:40 PST
Date: Thu, 21 Jan 88 14:58:57 PST
From: TC Rindfleisch <Rindfleisch@SUMEX-AIM.Stanford.EDU>
Subject: Re: Minutes of Facilities Committee meeting of 1/20/87
To: LES@SAIL.Stanford.EDU, facil@SAIL.Stanford.EDU, Nilsson@SCORE.STANFORD.EDU,
Reges@SCORE.STANFORD.EDU, BScott@SCORE.STANFORD.EDU,
AG@AMADEUS.STANFORD.EDU, MAYR@SCORE.STANFORD.EDU,
oliger@NAVAJO.Stanford.EDU
cc: Rindfleisch@SUMEX-AIM.Stanford.EDU
In-Reply-To: Message from "Les Earnest <LES@SAIL.Stanford.EDU>" of Wed, 20 Jan 88 19:42:00 PST
Message-ID: <12368467095.40.RINDFLEISCH@SUMEX-AIM.Stanford.EDU>
Les et al., for the record re the minutes on the POLYA discussion, I for one
was not fully convinced that ALL students need $75/month accounts. Seems like
the "pro" arguments centered on giving all students access to information
important to being members of CSD and which PORTIA management was not willing
to provide access to from their machine. I agree with this need but feel that
for many students (e.g., PhD and MS:AI students connected with research
projects), that this information can be copied to other mainframes or made
accessible from distributed workstations more cheaply than having a POLYA
account. $75/month for 50 KSL students comes to $45,000/year!
Tom R.
-------
∂21-Jan-88 1623 hilbert@alan.stanford.edu New math requirement
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 21 Jan 88 16:23:36 PST
Received: from alan.stanford.edu by russell.stanford.edu (3.2/4.7); Thu, 21 Jan 88 15:05:09 PST
Received: by alan.stanford.edu (3.2/4.7); Thu, 21 Jan 88 15:06:04 PST
Date: Thu 21 Jan 88 15:06:02-PST
From: Dave Hilbert <HILBERT@Alan.Stanford.EDU>
Subject: New math requirement
To: ssp-faculty@alan.stanford.edu
Message-Id: <569804762.0.HILBERT@Alan.Stanford.EDU>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@Alan.Stanford.EDU>
A math requirement has been added to the Symbolic Systems Core. The
requirement will be in effect for students who declare the major after
today. Current majors have the option of completing the requirements
that were in effect at the time they declared. A description of the
new requirement follows.
Dave Hilbert
Program Coordinator
[the following paragraph is to be inserted in the Offerings and
Facilities section of the introductory material in the curriculum
description.]
An important feature of the Symbolic Systems Program at Stanford is
that it stresses the mathematical and philosophical aspects of the
study of symbolic systems. Thus, in addition to courses in artificial
intelligence, computer science, linguistics, and psychology, students
are required in the core to prepare themselves both mathematically and
philosophically.
[What follows is the proposed new math requirement to be added to the
list of core requirements.]
Mathematics requirement.
Much of the work in symbolic systems is quite mathematical in nature.
Except for the basics of mathematical logic, there is no one branch of
mathematics that every student of symbolic systems will need. Rather,
what SSP students need to develop is enough mathematical experience
that they can pick up what mathematics they need without a great deal
of effort. Most SSP students take one of the two calculus sequences
as a matter of course. This is not a core requirement, but it is
strongly recommended. Two courses on mathematical topics other than
calculus are required. The courses should make the student acquainted
with proof techniques in mathematics, as well as with the use of
mathematics to model real world phenomena.
1. Two courses on mathematical topics other than calculus.
a) One course involving an introduction to basic mathematical
techniques, with applications. Examples of suitable courses
are: Phil. 159, Math. 103, Math. 109.
b) A second course involving more advanced mathematical
concepts of a more theoretical nature, involving the
systematic development of some part of mathematics.
Examples of suitable courses are Math. 120, Math. 162,
Stat. 115, Stat. 116, Stat. 110, CS. 260,
Phil 160B.
Other courses may be substituted for the suggested ones with the
approval of the program coordinator.
-------
∂21-Jan-88 2221 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU industrial lecturers
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Jan 88 22:21:12 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 21 Jan 88 22:16:01-PST
Date: 21 Jan 88 2220 PST
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: industrial lecturers
To: faculty@SCORE.STANFORD.EDU
It is time for suggestions for industrial lecturers next year. We need
one per quarter. Appropriate candidates are people from local
industry with something to say to our students not otherwise covered
in our courses. We need course descriptions from them in time to
put them in the catalog.
∂22-Jan-88 1134 @Score.Stanford.EDU:binford@anaconda.Stanford.EDU switching to Polya
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Jan 88 11:34:01 PST
Received: from anaconda.Stanford.EDU.stanfo (Anaconda.Stanford.EDU.#Internet) by SCORE.STANFORD.EDU with TCP; Fri 22 Jan 88 11:29:24-PST
Received: by anaconda.Stanford.EDU.stanford.edu (4.0/SMI-DDN)
id AA13346; Fri, 22 Jan 88 11:38:39 PST
Date: Fri, 22 Jan 88 11:38:39 PST
From: binford@anaconda.stanford.edu (Tom Binford)
Message-Id: <8801221938.AA13346@anaconda.Stanford.EDU.stanford.edu>
To: REGES@score.stanford.edu
Cc: ac@score.stanford.edu, ball@score.stanford.edu, tom@score.stanford.edu,
gotelli@score.stanford.edu, bureaucrats@score.stanford.edu
Subject: switching to Polya
re: strong objection
I strongly object to the proposed policy. This is like
976 numbers from the phone company.
We provide computing resources for our students. Those
costs do not decrease if students use other machines.
There is no general need met by POLYA or other CSD-CF run
machines which cannot be met by our facilities. With
research funding extremely tight, it is important to us
that students use our facilities rather than run large
costs in addition to the costs we already have.
If CSDCF feels inclined to give students accounts on their
machines, I feel no responsibility to cover those
unnecessary costs.
Tom Binford
∂22-Jan-88 1656 hilbert@alan.stanford.edu CSLI Internships
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 22 Jan 88 16:55:23 PST
Received: from alan.stanford.edu by russell.stanford.edu (3.2/4.7); Fri, 22 Jan 88 16:57:16 PST
Received: by alan.stanford.edu (3.2/4.7); Fri, 22 Jan 88 16:58:07 PST
Date: Fri 22 Jan 88 16:58:03-PST
From: Dave Hilbert <HILBERT@Alan.Stanford.EDU>
Subject: CSLI Internships
To: ssp-faculty@alan.stanford.edu
Message-Id: <569897883.0.HILBERT@Alan.Stanford.EDU>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@Alan.Stanford.EDU>
We would like to have a lunch for faculty interested in working with
students in the recently announced CSLI internship program and
students interested in the internships. The purpose of the lunch
would be to provide an opportunity for interested students and faculty
to have a chance to meet and discuss possible projects. At this
point, we are interested in whether there is faculty interest in such
a meeting. If you would like to attend please let me know so that we
can try to arrange a convenient time. Thanks.
Dave Hilbert
Program Coordinator
-------
-------
-------
∂22-Jan-88 1806 TAJNAI@Score.Stanford.EDU Invitation to the 20th Annual Meeting of the Computer Forum
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Jan 88 18:06:26 PST
Date: Fri 22 Jan 88 18:01:03-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Invitation to the 20th Annual Meeting of the Computer Forum
To: faculty@Score.Stanford.EDU
Message-ID: <12368762388.47.TAJNAI@Score.Stanford.EDU>
TO: CSD/CSL Faculty
FROM: Computer Forum Committee
SUBJECT: Twentieth Annual Meeting of the Stanford Computer Forum
It is with pleasure that the Forum Committee invites you to the 20th
Annual Meeting of the Stanford Computer Forum being held Tuesday -
Thursday, February 9/10/11, 1988
We encourage you to participate in all events: technical and social --
in particular, the luncheons, the banquet and the Thursday afternoon
reception. All meals are without charge and for invitees only. If
you wish to bring a guest to the banquet, the cost is $30; make checks
payable to the Stanford Computer Forum.
* An informal buffet will be held at the Faculty Club on Tuesday
evening, February 9 from 6 to 8 p.m. Breakfasts and lunches will be
held at Tresidder (second floor Large Lounge).
* Wednesday night banquet will be at the Faculty Club with social hour
starting at 6 p.m.; dinner at 7.
* The closing reception will be held at the Faculty Club on Thursday
from 4:30 to 6:00 p.m.
Appended is a meal reply form. It is important that we have an
accurate account of the meals you plan to attend because we have to
give an attendance guarantee. Respond to me or to Bonnie Hiller
(Hiller@Score) by Monday, February 1.
We look forward to a great 20th Annual Meeting!
_____ Buffet Supper Tues. 2/9 6:00 p.m. Faculty Club
_____ Breakwest Wed. 2/10 8:00 a.m. Tresidder
_____ Lunch Wed. 2/10 11:45 a.m. Tresidder
_____ Banquet Wed. 2/10 6:00 p.m. Social Hour,
7:00 p.m. Dinner,
Faculty Club
no RSVP necessary for continental breakfast Thursday morning at Tresidder
8:00 a.m.
_____ Lunch Thursday, 2/11 12:15 p.m. Tresidder
The Annual Meeting is for invited guests only. However, if you wish to
bring a guest to the banquet, the cost is $30@. Make check payable to
Stanford Computer Forum.
Important: Note any special dietary needs, e.g., meals low in salt, fat,
sugar. If vegetarian or keeping Kosher, please specify what you can eat.
-------
∂23-Jan-88 1137 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Polya Policy
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Jan 88 11:37:23 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Sat 23 Jan 88 11:31:44-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA23666; Sat, 23 Jan 88 11:35:56 PST
Date: Sat, 23 Jan 88 11:35:56 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8801231935.AA23666@Tenaya.stanford.edu>
To: faculty@score, csd@score
Subject: Polya Policy
I have read with interest the various proposals regarding
who should have accounts on Polya and the reactions to these
proposals.
Here is what I would like to see happen. (If there are
strong objections to the following from the faculty, perhaps
we should have a faculty meeting to discuss all of this.
Barring strong objections, I would presume that the facilities
committee will incorporate these ideas into their recommendations
to CSD-CF.)
1) The "tradition" of giving everyone free accounts (the "sushi
tradition") is too expensive for the Department to continue and
is unwarranted for the research projects to support. Since all
computers are networked at Stanford, the sense of community that
we want to foster does not require us all to be on the same
computer. (ALL of you are reading this message on a computer
different from the one I am on.)
2) The Department is committed to guaranteeing support for first-year
PhD students. (Usually this support comes from Departmental funds;
occasionally from research projects---when the student starts working
immediately with that research project.) This guarantee of support
should include computing, and therefore the Dept. should guarantee
computing for first-year PhD students. When such is not provided by a
research project, it will be provided on Polya and paid for by the
Department. Appropriate $ limits will undoubtedly have to be set on
Polya, and I leave it to negotiations between CSD-CF and the Dept
(with advice from the facilities committee and students) on what the $
limits should be for Polya first-year PhD accounts.
3) (Continuing with policy as it affects PhD students:) During the
second and subsequent years, PhD students are supposed to be "engaged"
in some way with a research project or with a faculty member doing
research. Ordinarily they will be supported by that research project,
and this support includes computer support. It is up to the research
project whether such computer support is provided by machines local to
the project or is to be provided by Polya (and paid for by the
research project!!) or both. In the case in which research projects
decide that students should have a Polya account these research
projects will be billed by CSD-CF for this student usage. This policy
applies even to students who have fellowships. When the fellowship
includes monies for computer support, such monies can be used to
purchase time on Polya or can be used to help pay for the research
machines, but it is to be expected that fellowship students working on
a research project will have to be provided computing support by the
project. (That is, when a faculty member takes on a PhD student and
agrees to be his/her adviser, such faculty member incurs the burden of
working out with the student how the student's computing needs will be
met; it is not up to the Dept. to finance these computing needs.)
When PhD students are working outside of Stanford (SRI, etc.), they
nevertheless have a Stanford faculty member as a primary adviser and
such faculty member is in charge of dealing with that student's
computing needs. Often, most of these computing needs will be
satisfied by computers at the remote site, but it is acknowledged that
the student ought to have a local Stanford account (probably Polya),
and I would think that the student's primary adviser should be
expected to support that local account. In rare cases, the Dept.
could support limited accounts for PhD students working with
outside-of-Stanford researchers.
4) In those, one would hope rare, cases in which PhD students work
with faculty who are (temporarily) unable to support the computing
needs of their students, such faculty member may attempt to arrange
with the Department for the Department to finance a Polya account for
the student. Such arrangements need to be made in the context of a
broader understanding between the Dept. and the faculty member about
the long-range plans for financing such faculty member's research.
Thus, a student who wants a Polya account past his/her first year
will first find a faculty member with whom he/she will be doing
research and will get that faculty member to apply for the account.
This places the burden on students to join a research project by
the beginning of their second year---but that is exactly what is
supposed to happen anyway.
[[The above policies derive from a more basic assumption about the way
research works at Stanford generally and in the CSD in particular.
Research and research support is the individual responsibility of each
individual faculty member---sometimes working in groups. The
Department has no separate research funds and has not played a role in
"taxing" research projects or obtaining funds from other sources to
support generic, departmental research. Wherever possible, the
Department tries to help new faculty and temporarily-unsupported
faculty with their research needs, but such help is usually temporary.
When a PhD student comes to Stanford, he/she supposedly understands
this tradition and adapts to it. Since later-than-first-year students
are engaged mainly in research, their computing needs are research
needs and must thus be financed by research projects. The
course-related educational needs of PhD students are mainly first-year
needs and will be adequately covered by Polya accounts for first-year
students. I didn't invent this tradition, but I am adapting to it
just as the students must.]]
5) The Department will pay for accounts for MS students up
to a certain limit (that will be set after discussions between
CSD-CF and the Department---taking into account the effect
on Departmental finances). It is to be expected that, in so
far as possible, much course work will be done on AIR machines
(e.g. Portia, etc.) If University budget policies dictate
severe limits on what the Dept. can afford regarding free computing
for students, the Dept. may have to consider a modest "lab
fee" to help support Polya student computing.
I realize that some will feel a Polya policy based on these
ideas is not sufficiently generous, but both financial
realities and departmental traditions regarding research
require it.
-Nils
∂23-Jan-88 1329 LOGMTC-mailer logic lunch
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 23 Jan 88 13:29:32 PST
Received: from alan.stanford.edu by russell.stanford.edu (3.2/4.7); Sat, 23 Jan 88 13:32:41 PST
Received: from localhost by alan.stanford.edu (3.2/4.7); Sat, 23 Jan 88 13:33:38 PST
To: logic@alan.stanford.edu
Subject: logic lunch
Date: Sat, 23 Jan 88 13:33:36 PST
From: Jon Barwise <barwise@alan.stanford.edu>
Logic lunch will resume on MOnday, in the lounge on the 3rd
floor of the math dept. Promise.
∂23-Jan-88 1425 REGES@Score.Stanford.EDU minor addition to POLYA policy
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Jan 88 14:25:09 PST
Date: Sat 23 Jan 88 14:19:47-PST
From: Stuart Reges <REGES@Score.Stanford.EDU>
Subject: minor addition to POLYA policy
To: faculty@Score.Stanford.EDU, csd@Score.Stanford.EDU
Office: CS-TAC 22, 723-9798
Message-ID: <12368984252.15.REGES@Score.Stanford.EDU>
I am currently planning on opening accounts for declared CS undergrads on POLYA
(unless someone convinces me otherwise). These accounts will be paid for by
money provided by the Provost for satisfying the special computing needs of
undergrads. I haven't raised this as an issue, because no Departmental
unrestricted funds will be used. The undergrads will also have a $$ limit, set
at a reasonable level to make sure we don't dip into Departmental money.
There is something of an issue regarding interdisciplinary majors. The CSE
major is so close to our own and is so small that it almost counts as
background noise, so I plan to offer accounts to CSE majors as well. Perhaps
that will encourage some students to go into the major. The Symbolic Systems
major, on the other hand, is quite different from our own, including tracks
with only minimal computer science, and is quite large. Math/Sci is similar.
As a result, I don't plan on giving POLYA accounts to those students.
I welcome any opinions regarding my plans for undergrad accounts.
-------
∂24-Jan-88 1835 FACIL-mailer Polya
To: Facil@SAIL.Stanford.EDU
From: Joe Weening <JSW@SAIL.Stanford.EDU>
[I sent the following message to Nils, who asked me to forward it here.
This is a slightly edited version.]
I've been reading the recent messages with interest. From my perspective
as a student who has worked closely with CSD-CF and department
administrative computing for many years, I think I understand all of the
sides of the issue fairly well.
A major factor causing the current problem is that many of the major
research groups are not participating in the use of Polya, e.g.,
Distributed Systems (using workstations), Formal Reasoning (SAIL and
Gang-of-Four), Robotics, KSL, and various other groups who have bought
Lisp machines or other specialized hardware. In many cases these
alternate resources are necessary, but this leaves the large timesharing
systems without support such as SAIL and Score had in the 1970s and early
1980s.
The costs of running Polya seem to be almost independent of the usage, yet
it is being billed on a usage basis. This makes its existence very
unstable: if there are enough users, the rates are low, attracting even
more users (until it becomes overloaded); if there are too few users, the
rates go up, driving away marginal users. This has been happening to SAIL
for the past three years or so, and it will soon die.
It looks like we're starting out Polya in a situation with too few users,
and it will have to fight for survival from the beginning. If there is
anything that can be done to attract people who currently don't use much
CSD-CF time but could (such as N.A. and Robotics), I think it would help.
Of course, since I haven't seen any budget figures this may all be
speculation on my part, but I don't think the current discussion would be
happening if things were otherwise.
Usage-based accounting also causes a great disincentive for anyone to do
experimental computing. Before 1980, there was no usage-based accounting
at all as far as I know. (I wasn't here then, of course.) Between 1980
and 1983, SAIL and Score charged based on disk allocation but not CPU or
connect time. In 1983, CPU and connect time accounting began, and my
impression is that major experimental work by students, at least, stopped
almost immediately. A few projects (Knuth's TeX and Gabriel's Lisp
benchmarks come to mind) have been done under the new system, but these
were done by people able to secure their own funding. In recent years, I
have often heard of students being told by their advisors to curb their
computer usage, because of lack of funds.
I don't see any easy solutions. I feel fortunate that I'm working with
John McCarthy, who has never told me to avoid using any computers because
of what it was costing. I hope that the rest of the faculty can come up
with funding to do the same.
Last month I visited MIT for the first time. I saw firsthand what they
provide for students, and how much freer the computing atmosphere there
is. Somehow they are able to pull it off, so there must be a way for us
to do it too.
Joe
∂25-Jan-88 0848 RICHARDSON@Score.Stanford.EDU Awards Summary for Fiscal Year 1986
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Jan 88 08:48:13 PST
Date: Mon 25 Jan 88 08:41:42-PST
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: Awards Summary for Fiscal Year 1986
To: faculty@Score.Stanford.EDU
Message-ID: <12369446993.38.RICHARDSON@Score.Stanford.EDU>
Hello. This message is to announce that there is a Summary of Awards booklet
from the National Science Foundation for the Fiscal Year 1986. This awards
announcement covers the Division of Information, Robotics and Intelligent
Systems. Please drop by MJH 214 if you would like to look at this booklet.
Heidi Schubert
Nils Nilsson's Office
-------
∂25-Jan-88 0930 @Score.Stanford.EDU:ball@navajo.stanford.edu Any interest in the B & H Film Recoder
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Jan 88 09:30:29 PST
Received: from navajo.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 25 Jan 88 09:23:46-PST
Received: by navajo.stanford.edu; Mon, 25 Jan 88 09:24:00 PST
Date: Mon, 25 Jan 88 09:24:00 PST
From: James E. Ball <ball@navajo.stanford.edu>
Subject: Any interest in the B & H Film Recoder
To: FACULTY@score.stanford.edu
We have a BeLL & Howell Color Digital Imager IV Film Recorder. The
unit was given to the department about one year ago by Bell & Howell.
Unfortunately the system is unusable in it's present state as it needs
to be driven by a PC. The software supplied with the system runs on a
PC and provides screen copy facilities or HP plotter emulation.
Documentation supplied with the unit provides very little insight into
the actual commands to the unit. Our approach to using the system was
to buy a PC with color graphics and use the software provided by B & H
rather than make a major project out of it.
The system would be set up in stand alone mode with a PC set up to act
as a graphics preparation workstation. This might result in less than
desirable resolution due to the limitation of the IBM Color Graphics
mode the unit is programmed to work with. Higher resolution would be
possible but only after some software development work. The system
uses a standard 35mm Camera Body and Polaroid Polachrome instant slide
film. It also has a flat film pack body for Polaroid 669 type film.
There is a good deal of button pushing and film handling during use.
CSD-CF estimates that it would cost about $4,000 to buy a PC and get
the unit set up. The costs would be recovered by establishing a charge
per use or roll of film or per session. The real issue is whether or
not there would be sufficient use of the system to pay for it.
Please let us know if you would like to see this system made available
for use. We would also like to have an estimate of how often you would
use it and the approximate volume of slides. We will use this
information to decide the disposition of the unit.
Jim
∂25-Jan-88 1016 ULLMAN@score.stanford.edu [<KERSCH%GMUVAX.BITNET@forsythe.stanford.edu>: Advance Program: Expert Database Systems Conference]
Received: from navajo.stanford.edu by SAIL.Stanford.EDU with TCP; 25 Jan 88 10:16:42 PST
Received: from Score.Stanford.EDU by navajo.stanford.edu with TCP; Mon, 25 Jan 88 10:07:18 PST
Date: Mon 25 Jan 88 10:06:25-PST
From: Jeffrey D. Ullman <ULLMAN@score.stanford.edu>
Subject: [<KERSCH%GMUVAX.BITNET@forsythe.stanford.edu>: Advance Program: Expert Database Systems Conference]
To: nail@navajo.stanford.edu
Message-Id: <12369462415.9.ULLMAN@Score.Stanford.EDU>
Return-Path: <KERSCH%GMUVAX.BITNET@forsythe.stanford.edu>
Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Sun 24 Jan 88 08:18:32-PST
Received: by lindy.stanford.edu; Sun, 24 Jan 88 08:23:33 PST
Received: by Forsythe.Stanford.EDU; Sun, 24 Jan 88 08:22:15 PST
Date: Sun, 24 Jan 88 10:53 EST
From: <KERSCH%GMUVAX.BITNET@forsythe.stanford.edu>
Subject: Advance Program: Expert Database Systems Conference
To: ullman@score.stanford.edu
X-Original-To: pgray%csvax.aberdeen.ac.uk@Cs.Ucl.AC.UK,
stamper%vax1.lse.ac.uk@Cs.Ucl.AC.UK, sagiv%hugo%israel.csnet@relay.cs.net,
salveter%bostonu.csnet@relay.cs.net,
oshmu%tech-sel%israel.csnet@relay.cs.net, ullman@SCORE.STANFORD.EDU, KERSCH
ADVANCE PROGRAM
The Second International Conference on
Expert Database Systems
April 25-27, 1988
Sheraton Premiere at Tysons Corner, Virginia
Sponsored by: George Mason University
In Cooperation With: American Association for Artificial Intelligence
Association for Computing Machinery - SIGART and SIGMOD
IEEE Computer Society - T. C. on Data Engineering
Conference Objectives
---------------------
The International Conference on Expert Database Systems has
established itself as a leading edge forum that explores the
theoretical and practical issues in making database systems more
intelligent and supportive of Artificial Intelligence (AI)
applications. Expert Database Systems represent the confluence of R&D
activities in Artificial Intelligence, Database Management, Logic and
Logic Programming, Information Retrieval, and Fuzzy Systems Theory.
It is precisely this synergism among disciplines which makes the
Conference both stimulating and unique.
Organizing Committee
--------------------
Conference Chairman
Edgar H. Sibley, George Mason University
Program Chairman
Larry Kerschberg, George Mason University
Program Committee
-----------------
Robert Abarbanel, IntelliCorp
Hideo Aiso, Keio University
Antonio Albano, Univ. di Pisa
Stephen Andriole, GMU
Robert Balzer, USC/ISI
Francois Bancilhon, GIP Altair, France
Don Batory, Univ. of Texas
Alex Borgida, Rutgers University
Michael Brodie, GTE Labs, Inc.
Janis Bubenko, Univ. of Stockholm
Peter Buneman, Univ. of Pennsylvania
Stefano Ceri, Politecnico di Milano
Umesh Dayal, Computer Corp. of America
Mark Fox, Carnegie-Mellon University
Antonio L. Furtado, IBM do Brasil
Herve Gallaire, ECRC, FRG
Barbara Hayes-Roth, Stanford University
Yannis Ioannidis, Univ. of Wisconsin
Sushil Jajodia, National Science Foundation
Matthias Jarke, Univ. of Passau
Jonathan King, Teknowledge, Inc.
Roger King, Univ. of Colorado
Robert Meersman, Tilburg University
Tim Merrett, McGill University
Matthew Morgenstern, SRI International
John Mylopoulos, Univ. of Toronto
Sham Navathe, Univ. of Florida
Erich Neuhold, GMD, FRG
Setuo Ohsuga, Univ. of Tokyo
Stott Parker, UCLA
Alain Pirotte, Philips Research Lab
Don Potter, Univ. of Georgia
Larry Reeker, BDM Corporation
Nick Roussopoulos, Univ. of Maryland
Erik Sandewall, Linkoping University
Timos Sellis, Univ. of Maryland
John Smith, Kendall Square Research
Reid Smith, Schlumberger Palo Alto Res.
Arne Solvberg, Univ. Trondeim
John Sowa, IBM SRI
Jacob Stein, Servio Logic Dev. Corp.
Michael Stonebraker, UC - Berkeley
Adrian Walker, IBM TJ Watson Center
Andrew Whinston, Purdue University
Gio Wiederhold, Stanford University
Eugene Wong, UC - Berkeley
Carlo Zaniolo, MCC
Tutorial and Panel Coordinator
Lucian Russell, Computer Sciences Corp.
Conference Coordinators
Juliette Gregory and Barbara Framer, GMU
Exhibit Coordinators
Diane Tosh Entner, RAMCOR, REassociates
Carolyn Komada, E-Systems, Melpar
Publicity Chairman
Jorge Diaz-Herrera, GMU
Conference Organization and Fee Structure
-----------------------------------------
The three day EDS Conference is organized into the Technical Program
and a concurrent Tutorial Program. There are separate fees for each,
and a special Conference/Tutorial Package fee is also available.
The Conference Fee includes the Technical Program consisting of the
Keynote Address, Paper Sessions with twenty-seven high-quality papers,
three Panels, Proceedings, Exhibits and Vendor Presentations, three
Luncheons, Coffee Breaks, a Hospitality Hour and our Theme Party,
Campaign Capers. The Spirit of Washington Cruise is an optional
social event. Space is limited for the cruise, and early registration
is required.
The Tutorial Program consists of four half-day tutorials, running
concurrently with the Technical Program. It is designed to provide
participants with the latest concepts, tools and techniques related to
R&D in Expert Database Systems. You may enroll for up to four
tutorials. Each tutorial includes tutorial notes, a coffee break and
a luncheon. Thus, participants may choose to attend only tutorials
without attending the Conference. Tutorial participants may purchase
Social Function tickets separately.
The Conference/Tutorial Package is designed to allow conference
participants to attend tutorials at reduced rates, enabling
participants to concentrate on special interest areas of EDS.
Exhibits and Vendor Presentations
---------------------------------
Leading Artificial Intelligence and Database companies plan to exhibit
a range of hardware and software products.
In addition to the exhibits, special sessions are planned for vendor
product briefings and prototype demonstrations. At this writing, the
following vendor presentations have been confirmed: Introduction to
the Application Expert, Cullinet, USA; The KEE Connection,
IntelliCorp, USA; Copernicus, A Modular Tool for Managing Knowledge
and Data, Teknowledge, Inc., USA; and Relational LISP, MAD Computing, USA.
Also, several well-known publishing companies will offer their latest
titles in the fields of Expert Database Systems, Artificial
Intelligence, Expert Systems and Database Management.
Social Functions
----------------
Campaign Capers: Participate in the Expert Database Systems
Conference Presidential Preference Primary! Caucus with your
conference associates to determine who will win the U.S. Presidential
Election in 1988. Participate in the quintessential Washington
activity as you vote for the candidate of your choice, move to
republican rhythms and democratic dances, and enjoy regional American
cuisine and a cash cocktail bar.
Spirit of Washington Cruise: Sail and celebrate springtime in
Washington! Enjoy dinner and a musical Broadway revue as you cruise
on the Potomac River, past Washington's historic landmarks. Be
spirited away on the Spirit of Washington.
Note: The cruise is an optional event, and space on the Spirit of
Washington is limited, so we recommend that you reserve your place
when sending in your Conference Registration Form.
============================
Conference Technical Program
============================
---------------------
Monday, April 25, 1988
----------------------
8:45-9:00 am Opening Remarks
Chairman: Edgar H. Sibley, George Mason University, USA
9:00-10:00 am Keynote Address
Chairman: Larry Kerschberg, George Mason University, USA
Future Directions in Expert Database Systems
Michael Stonebraker, Univ. of California at Berkeley, USA
10:00-10:30 am Coffee Break
10:30-12:00 am Object-Oriented Systems
Chairman: Jacob Stein, Servio Logic, USA
Abstract Objects in an Object-Oriented Data Model
J. Zhu and D. Maier, Oregon Graduate Center, USA
KIVIEW: An Object-Oriented Browser
A. Motro, Univ. of Southern California, USA, A. D'Atri and L.
Tarantino,
Univ. of Rome, Italy
Towards a Unified View of Design Data and Knowledge Representation
B. Mitschang, Universitat Kaiserslautern, FRG
12:00-1:30 pm Luncheon
1:30- 3:00 pm Constraint Management
Chairmen: Herve Gallaire, ECRC, FRG and Alain Pirotte, Philips Labs, Belgium
Implementing Constraints in a Knowledge-Base
J.A. Wald, Schlumberger-Doll Research, USA
Update-Oriented Database Structures
L. Tucherman and A.L. Furtado, IBM Rio Scientific Center, Brazil
Distribution Design of Integrity Constraints
X. Qian, Stanford University, USA
3:00-3:30 pm Coffee Break
3:30-5:00 pm Panel: Constraint-Based Systems: Knowledge about Data
Chairman: Matthew Morgenstern, SRI International, USA
5:30-6:30 pm Hospitality Hour
7:00-10:00 pm Campaign Capers
-----------------------
Tuesday, April 26, 1988
-----------------------
8:30-10:00 am Expert Database System Architectures
Chairmen: Robert Meersman, Tilburg University, and Sushil Jajodia, NSF
BERMUDA - An Architectural Perspective on Interfacing Prolog to a
Database Machine
Y.E. Ioannidis, J. Chen, M.A. Friedman and M.M. Tsangaris, U. of Wisconsin
A Look at Loosely-Coupled Prolog/Database Systems
B. Napheys and D. Herkimer, Martin Marietta, USA
Combining Top Down and Bottom Up Computation in Knowledge Based Systems
M. Nussbaum, ETH, Switzerland
10:00-10:30 am Coffee Break
10:30-12:00 am Morning Parallel Sessions
IA: Knowledge/Data System Architectures
Chairmen: Roger King, Univ. of Colorado and Robert Abarbanel, IntelliCorp
A Distributed Knowledge Model for Multiple Intelligent Agents
Y.P. Li, Jet Propulsion Laboratory, USA
The Relational Production Language: A Production Language for
Relational Databases
L.M.L. Delcambre and J.N. Etheredge, U. of Southwestern Louisiana, USA
A Transaction Oriented Mechanism to Control Processing in a Knowledge
Base Management System
L. Raschid, Univ. of Maryland, USA
IB: Recursive Query Processing
Chairman: Tim H. Merrett, McGill University
Transitive Closure of Transitively Closed Relations
P. Valduriez and S. Khoshafian, MCC, USA
Transforming Nonlinear Recursion to Linear Recursion
Y.E. Ioannidis, Univ. of Wisconsin and E. Wong, UC-Berkeley, USA
A Compressed Transitive Closure Technique for Efficient Fixed-Point
Query Processing
H.V. Jagadish, AT&T Bell Laboratories, USA
12:00-1:30 pm Luncheon
1:30-3:00 pm Afternoon Parallel Sessions
IIA: Learning and Adaptation in Expert Databases
Chairmen: Alex Borgida, Rutgers University and Don Potter, Univ. of Georgia
An Automatic Improvement Processor for an Information Retrieval System
K.P. Brunner, Merit Technology, Inc. and R.R. Korfhage, Univ. of
Pittsburgh, USA
Supporting Object Flavor Evolution through Learning in an
Object-Oriented Database System
Q. Li and D. McLeod, Univ. of Southern California, USA
Implicit Representation of Extensional Answers
C.D. Shum and R. Muntz, UCLA, USA
IIB: Knowledge Management in Deductive Databases
Chairmen: Sham Navathe, U. of Florida and Francois Bancilhon, GIP Altair
Deep Compilation of Large Rule Bases
T.K. Sellis and N. Roussopoulos, Univ. of Maryland, USA
Handling Knowledge by its Representative
C. Sakama and H. Itoh, ICOT, Japan
Integrity Constraint Checking in Deductive Databases using a Rule/Goal Graph
B. Martens and M. Bruynooghe, Katholieke Universiteit Leuven, Belgium
3:00-3:30 pm Coffee Break
3:30-5:00 pm Panel: Knowledge Distribution and Interoperability
Chairman: Michael Brodie, GTE Labs, USA
6:00-11:00 pm Spirit of Washington Cruise
-------------------------
Wednesday, April 27, 1988
-------------------------
9:00-10:30 am Intelligent Database Interfaces
Chairmen: Erich Neuhold, GMD, FRG and Larry Reeker, BDM Corp.
Musing in an Expert Database
S. Fertig and D. Gelernter, Yale University, USA
Cooperative Answering: A Methodology to Provide Intelligent Access
to Databases
F. Cuppens and R. Demolombe, ONERA-CERT, France
G+: Recursive Queries without Recursion
I.F. Cruz, A.O. Mendelzon and P.T. Wood, Univ. of Toronto, Canada
10:30-11:00 am Coffee Break
11:00-12:30 pm Semantic Query Optimization
Chairman: Matthias Jarke, Univ. of Passau, FRG
Automatic Rule Derivation for Semantic Query Optimization
M.D. Siegel, Boston University, USA
A Metainterpreter to Semantically Optimize Queries in Deductive Databases
J. Lobo and J. Minker, Univ. of Maryland, USA
From QSQ towards QoSaQ: Global Optimization of Recursive Queries
L. Vieille, ECRC, FRG
12:30-2:00 pm Luncheon
2:00-3:30 pm Panel: Knowledge Management
Chairman: Adrian Walker, IBM T.J. Watson Research Center, USA
Panelists: R. Kowalski, Imperial College, London, D. Lenat, MCC,
Austin, E. Soloway, Yale University and M. Stonebraker, UC - Berkeley
=========================
Tutorial Program
=========================
Tutorial I - Monday Afternoon, April 25, 1:30 pm - 5:00 pm
Logic and Databases
Instructor: Dr. Carlo Zaniolo, MCC, Austin, Texas
Dr. Zaniolo heads a group at MCC performing research on deductive
databases and logic programming. He has held positions at Sperry
Research and Bell Laboratories. He is the author of over 40 technical
papers, a member of numerous Program Committees, and edited the
December 1987 Data Engineering special issue on Databases and Logic.
Course Description: There is a growing demand for supporting
knowledge-based applications by means of Knowledge Management Systems;
these will have to combine the inference mechanisms of Logic with the
efficient and secure management of data provided by Database
Management Systems(DBMS). The major topics are: Logic and relational
query languages; Semantics of Horn Clauses; Prolog and DBMSs; Coupling
Prolog with a DBMS; Making Prolog a database language; Integrating
Logic and Database Systems: Sets, Negation and Updates; Choosing an
Execution Model; Compilation: magic sets to support recursive
predicates; Optimization and Safety; Overview of selected R&D
projects.
-------------------------------------------------------------------
Tutorial II - Tuesday Morning, April 26, 8:30 am - 12:00 am
Distributed Problem Solving in Knowledge/Data Environments
Instructor: Prof. Victor Lesser, University of Massachusetts,
Amherst, MA
Dr. Lesser is Professor of Computer and Information Science at UMASS,
where he heads research groups in Distributed Artificial Intelligence
and Intelligent User Interfaces. Prior to joining UMASS in 1977, he
was on the faculty of Carnegie-Mellon University, where he was a
Principal in the development of the HEARSAY Speech Understanding
System and responsible for the system architecture.
Course Description: This tutorial will explore the major concepts and
systems for cooperative knowledge-based problem solving. The major
topics include: Connectionist, Actor and Cooperating ES paradigms;
Conceptual Issues including: examples of distributed search,
interpretation, planning and cooperation, global coherence, dealing
with inconsistency and incompleteness, sharing world views, and design
rules for a cooperating ES; System Architectures for satisficing,
negotiation, tolerance of inconsistency in problem-solving,
organizational structuring, integration of local and network control,
and expectation-driven communication; Discussion of working systems
including Contract Nets, Partial Global Planning, AGORA MACE, ABE,
DPS, and MINDS; and Future Directions.
-----------------------------------------------------------------------
Tutorial III - Tuesday Afternoon, April 26, 1:30 pm - 5:00 pm
Knowledge Representation and Data Semantics
Instructor: Prof. John Mylopoulos, University of Toronto, Canada
Dr. John Mylopoulos is Professor of Computer Science at the University
of Toronto and research fellow of the Canadian Institute for Advanced
Research. His research interests include knowledge representation and
its applications to Databases and Software Engineering. Dr.
Mylopoulos has edited three books on the general topic of AI and
Databases. He received his Ph.D degree from Princeton University.
Course Description: Knowledge Representation including history, basic
paradigms such as semantic nets, logic-based representations,
productions, frames, role of uncertainty, and inference mechanisms,
examples such as KL-ONE and OMEGA; Semantic Data Models including
historical models such as Abrial's Binary Model, Entity/Relationship,
RM/T and SDM, detailed study of ADAPLEX, TAXIS, and GALILEO,
implementation techniques; Comparison of SDMs to Object-Oriented model
such as POSTGRES and GEM as well as Deductive Databases.
------------------------------------------------------------------------
Tutorial IV - Wednesday Morning, April 27, 9:00 am - 12:30 pm
Acquisition of Knowledge from Data
Instructor: Prof. Gio Wiederhold, Stanford University, Stanford,
California
Dr. Gio Wiederhold is Associate Professor of Medicine and Computer
Science (Research) at Stanford University. His research involves
knowledge-based approaches to medicine, design, and planning. He is
the Editor-in-Chief of ACM's Transactions on Database Systems and
associate editor of M.D. Computing and IEEE Expert magazine.
Wiederhold has over 130 publications, including a widely used textbook
on Database Design. In 1987, McGraw-Hill published his new book, File
Organization for Database Design.
Course Description: The architecture of an operational system, RX, is
presented which uses knowledge-based techniques to extract new
knowledge from a large clinical database. RX exploits both
frame-based knowledge and rules, as well as a database. Frames are
used to store deep and interconnected knowledge about disease states
and medical actions. Definitional and causal knowledge is
represented by inter-connections between frames that go across the
hierarchies, sideways as well as up and down, so that the aggregate
knowledge is represented by a network. Rules select the appropriate
statistical methods used to reduce the volume of data into
information. The database contains observations on rheumatic
diseases, collected over a dozen years.
-------------------------------------------------------------------------
Travel Arrangements
-------------------
The official travel agent for EDS'88 is: ALL Travel, Four Seasons One
Building, 3016 Williams Dr., Suite 1, Fairfax, VA 22031, USA. All
Travel's toll-free number is 1-800-338-8137; TELEX No. 910-250-1473
with Answer Back ALLTVL UQ. Please mention the Expert Database
Conference when making reservations. All Travel offers substantial
discounts for EDS'88 participants for International and Domestic
Flights on Pan Am, Delta, and United.
Airports and Ground Transportation
----------------------------------
The EDS'88 Conference Hotel is the Sheraton Premiere, located about 15
miles from the Washington Dulles International Airport. Both domestic
and international flights use Dulles. The Sheraton provides free
shuttle service from Dulles, leaving every hour on the hour, and
picking up passengers on the Arrivals Level between Baggage Areas 1
and 2. The Washington National Airport is convenient for many
Domestic Flights, and taxi service is available.
For those driving, the Sheraton offers free parking, and is located at
8661 Leesburg Pike at Tyson's Corner, about two miles West of the
Beltway (I-495).
Conference and Tutorial Fee Instructions
----------------------------------------
The Conference and Tutorial Fees table below shows the fee structure
for a) Conference only, b) Tutorials only, and c) the
Conference/Tutorial Package. First, decide whether you are going to
attend a), b) or c). If you are attending tutorials, decide how many
and check the appropriate number under b) or c). Finally, on the row
you have checked, circle the appropriate amount based on Early (on or
before March 21) or Late (after March 21) registration, and the
appropriate membership category: Member, Regular, or Student.
The Member rate applies to members of our cooperating societies:
AAAI, ACM or IEEE. The Regular rate applies to non-members of these
societies, and the Student rate applies to students.
Please Fill in the Form below and detach between the "========"
delimiters. Return the Hotel form directly to the Sheraton.
=======================================================================
Conference and Tutorial Fees
----------------------------
--------------------------------------------------------------------
On or Before March 21 | After March 21
--------------------------------------------------------------------
Mem. Reg. Stu. | Mem. Reg. Stu
--------------------------------------------------------------------
a) Conf. only ___ $250 $320 $100 | $300 $370 $150
--------------------------------------------------------------------
b) Tutorials only,
check qty. desired
One ___ $170 $170 $100 | $180 $180 $110
Two ___ $300 $300 $180 | $320 $320 $200
Three ___ $380 $380 $220 | $410 $410 $250
Four ___ $450 $450 $250 | $490 $490 $290
--------------------------------------------------------------------
c) Conf./Tut. Package
check qty. desired
One ___ $370 $440 $200 | $420 $490 $250
Two ___ $450 $520 $280 | $500 $570 $330
Three ___ $510 $580 $320 | $560 $630 $370
Four ___ $550 $620 $350 | $600 $670 $400
--------------------------------------------------------------------
Conference Registration Form
----------------------------
All payments must be in U.S. Dollars. Methods of payment are check,
bank drafts, Visa or Mastercard.
Make checks payable to the: GMU Foundation.
For telephone queries call (703) 323-2198. Send
completed registration form and remittance to:
EDS Conference
Office of Community Services, Div. of Continuing Education
George Mason University
4400 University Drive
Fairfax, VA 22030, USA
Name _________________________________________________
Organization _________________________________________________
Address _________________________________________________
City, State, ZIP _______________________________________________
Country _______________________________________________
Business Phone _________________________________________________
AIII/ACM/IEEE # _________________________________________________
Credit Card: VS or MC (circle one) No___________________________
Expiration Date _______ and
Signature: __________________________________________________
Tutorials selected (if applicable):
___ I: Logic and Databases ___ II: Distributed AI/DB Environments
___ III: K.R. & Data Semantics ___ IV: Acqusition of Knowledge from Data
Additional Social Function tickets may be purchased. Indicate
quantities below:
___ Campaign Capers @ $50
___ Spirit of Washington @ $35 (Note this is an optional event;
register early!).
Total Amount Included _________________________________________
========================================================================
Hotel Reservation Form: Please fill out the form and mail by April 4
to: Sheraton Premiere at Tysons Corner, 8661 Leesburg Pike, Vienna,
VA 22180, USA
######################################################################
Second International Conference on Expert Database Systems
April 24-27, 1988
Special Rates: $90 for Single/Double, $99 Triple
Suite Rates Available Upon Request
PLEASE PRINT
Name ________________________________________________________________
last first
Street _________________________________________________________
City ________________________ State _____________ Zip _________
Arrival Date ______________________________________________________
day of week month date time
Departure Date _____________________________________________________
day of week month date
Please Reserve ____________________ room(s) for ___________ persons(s)
NAMES OF PERSONS SHARING ACCOMMODATIONS
________________________________________________________________________
Rollaway -- $15 extra per night
Reservations must be received at the hotel by APRIL 4, 1988.
Reservations received after this date will be accepted on a space and
rate available basis only.
-------------------
GUARANTEED RESERVATIONS
-------------------
First Night Deposit of Major Credit Card for any arrival after 4 PM.
A guaranteed payment assures you that a room will be held for your day
of arrival. The room will become available for resale if you have not
registered by 6:00 AM THE FOLLOWING MORNING. You will be billed for
the first night's room & tax revenue if the reservation is not
cancelled before 6PM (EST) on the day of arrival. Please ask the
clerk for a cancellation number (703/448-1234).
GUARANTEE INFORMATION: (Please Print).
Firm Name ________________________________________________
Address __________________________________________________
City ________________________ State _____________ Zip _________
Home Phone ____________________ Business Phone ____________________
Credit Card ____________________________________________________
AX, VISA, MC, DC, CB (circle one)
Expiration Date: _________________________
Signature: _____________________________________________________
CHECK OUT TIME IS 12 Noon; ROOMS WILL NOT BE READY FOR YOUR ARRIVAL
UNTIL 3 PM.
#####################################################################
-------
∂25-Jan-88 1039 @Score.Stanford.EDU:hayes.pa@Xerox.COM Re: minor addition to POLYA policy
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Jan 88 10:39:45 PST
Received: from Xerox.COM by SCORE.STANFORD.EDU with TCP; Mon 25 Jan 88 10:33:30-PST
Received: from Salvador.ms by ArpaGateway.ms ; 25 JAN 88 10:33:07 PST
Date: 25 Jan 88 10:32 PST
From: hayes.pa@Xerox.COM
Subject: Re: minor addition to POLYA policy
In-reply-to: Stuart Reges <REGES@Score.Stanford.EDU>'s message of Sat, 23 Jan 88
14:19:47 PST
To: faculty@Score.Stanford.EDU, csd@Score.Stanford.EDU
Message-ID: <880125-103307-2124@Xerox>
Whoops, that last message of mine was meant for Stuart only.
Sorry, please forget you saw it.
Pat
∂25-Jan-88 1047 @Score.Stanford.EDU:hayes.pa@Xerox.COM Re: minor addition to POLYA policy
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Jan 88 10:47:15 PST
Received: from Xerox.COM by SCORE.STANFORD.EDU with TCP; Mon 25 Jan 88 10:33:36-PST
Received: from Cabernet.ms by ArpaGateway.ms ; 25 JAN 88 10:34:13 PST
Date: 25 Jan 88 10:28 PST
From: hayes.pa@Xerox.COM
Subject: Re: minor addition to POLYA policy
In-reply-to: Stuart Reges <REGES@Score.Stanford.EDU>'s message of Sat, 23 Jan 88
14:19:47 PST
To: REGES@Score.Stanford.EDU
cc: faculty@Score.Stanford.EDU, csd@Score.Stanford.EDU
Message-ID: <880125-103413-2127@Xerox>
I have fairly strong views on your policy for discrimination between different
interdisciplinary majors. Either there should be a policy of CS-only, which
makes sense, or students from all interdisciplinary majors should be supported
equally.
The argument against such discrimination is precisely the obverse of your remark
that giving accounts to CSE students might encourage students to go into the
major: presumably not having such accounts available may discourage some
students from going into Math/Sci or Symbolic Systems. It is important not to
be seen as exercising discrimination against some majors. As well as being
intellectually untenable, such a policy might not be consistent with the
intended uses of the Provosts special funds.
Your arguments that the Math/Sci and Symbolic Systems majors are large and have
minimal computer-science tracks seem to be selfdefeating, since presumably only
the students with an interest in the computer-science aspects will be interested
in using the accounts.
Pat Hayes
∂25-Jan-88 1317 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talks
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Jan 88 13:17:03 PST
Date: Mon 25 Jan 88 13:04:16-PST
From: Anil R. Gangolli <GANGOLLI@Sushi.Stanford.EDU>
Subject: Upcoming AFLB Talks
To: aflb.all@Sushi.Stanford.EDU
Office Phone: (415) 723-3605
Message-ID: <12369494794.60.GANGOLLI@Sushi.Stanford.EDU>
PLEASE NOTE:
* We really need speakers this quarter. If you
would like to talk, please contact me:
gangolli@SUSHI.STANFORD.EDU
THIS WEEK:
28-January-1988: Algorithms For Lunch Bunch
Problem Session
Participants are requested to present problems with or without
solutions, or with incomplete solutions for brainstorming, discussion
and solution.
Please contact me (gangolli@sushi.stanford.edu) if you have a problem
whose presentation might require a substantial portion of the meeting
period.
*** Time and Place: 12:30pm, Th, Jan. 28, Margaret Jacks Hall (MJH), Room 352
NEXT WEEK:
4-February-1988: Nir Shavit
Toward a Non-Atomic Era:
L-Exclusion as a Test Case
Most of the research in concurrency control has been based on the
existence of strong synchronization primitives such as test and set.
Following Lamport, recent research promoting the use of weaker
``safe'' rather then ``atomic'' primitives has resulted in
construction of atomic registers from safe ones, in the belief that
they would be useful tools for process synchronization. It has been
shown that using such atomic registers it is impossible to create
strong synchronization primitives such as test and set. We therefore
advocate a different approach, to skip the intermediate step of
achieving atomicity, and solve problems directly from safe registers.
We show how to achieve a fair solution to $\ell$-exclusion, a problem
previously solved assuming a very powerful form of test and set. We
do so using safe registers alone and without introducing atomicity.
The solution is based on the construction of simple novel
synchronization primitives that are non-atomic.
*** Time and Place: 12:30pm, Th, Feb. 4, Margaret Jacks Hall (MJH), Room 352
-------
∂25-Jan-88 1358 Zaenen.pa@Xerox.COM a little lexical celebration
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 25 Jan 88 13:58:34 PST
Received: from Xerox.COM by russell.stanford.edu (3.2/4.7); Mon, 25 Jan 88 13:46:24 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 25 JAN 88 13:29:16 PST
Date: 25 Jan 88 13:28 PST
From: Zaenen.pa@Xerox.COM
Subject: a little lexical celebration
To: research@russell.stanford.edu
Message-Id: <880125-132916-2486@Xerox>
To celebrate the fact that, thanks to Anil Gupta and Martin Kay's efforts, the
on-line dictionary is now ready to be used, we'll have a little celebration this
coming Thursday at 3:30 (normal tea hour)
Annie
∂25-Jan-88 1426 RICHARDSON@Score.Stanford.EDU faculty lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Jan 88 14:26:43 PST
Date: Mon 25 Jan 88 14:19:29-PST
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: faculty lunch
To: faculty@Score.Stanford.EDU
Message-ID: <12369508486.18.RICHARDSON@Score.Stanford.EDU>
This message is to announce that Nils will be out of town until next Monday,
February 1, but there will still be a faculty lunch tomorrow at the usual
time in MJH 146. Enjoy your lunch with your colleagues.
Heidi
-------
∂25-Jan-88 1442 STAGER@Score.Stanford.EDU Fall Quarter Tau Beta Pi
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Jan 88 14:41:41 PST
Date: Mon 25 Jan 88 14:20:43-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: Fall Quarter Tau Beta Pi
To: faculty@Score.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12369508710.25.STAGER@Score.Stanford.EDU>
The Fall Quarter Tau Beta Pi survey results have arrived and will be
delivered by our courier this afternoon.
Claire
-------
∂25-Jan-88 1536 SHEL@ibm.com help
Received: from navajo.stanford.edu by SAIL.Stanford.EDU with TCP; 25 Jan 88 15:36:12 PST
Received: from ibm.com by navajo.stanford.edu with TCP; Mon, 25 Jan 88 15:28:24 PST
Date: Mon, 25 Jan 88 15:28:41 PST
From: Shel Finkelstein <Shel@ibm.com>
To: NAIL@navajo.stanford.edu
Message-Id: <880125.152841.shel@IBM.com>
Subject: help
∂26-Jan-88 1107 X3J13-mailer voting
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 88 11:07:26 PST
Date: 26 Jan 1988 14:06-EST
Sender: MATHIS@A.ISI.EDU
Subject: voting
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]26-Jan-88 14:06:48.MATHIS>
At the upcoming meeting (March 14-18, including subcommittees)
in Palo Alto, I expect that we may be voting on some things.
After reviewing the attendance records of the last two meetings,
the following members representatives will be eligible
to vote (assuming they have also paid their X3 service fee).
If there are any questions or corrections, please contact me
as soon as possible.
-- Bob
Company Name Cambridge
====================================
Ft. Collins
A.I. Architechs X
Aerospace X
Alliant X
Bath, U. X X
CSC X
DEC X X
Edinburgh, U. X X
Encore X
Evans & Southerland X
Franz X X
Gensym X
Gigamos X X
GMD X
Goldhill X X
Gould X
Grumman X X
Hewlett Packard X X
Honeywell X X
IBM X X
ILOG S.A. X
INRIA X
Internat. Lisp Assoc. X
Johnson Controls X X
Lucid X X
Mathis X X
MCC X X
Micro. Sys. Consults. X
MIT X
Mitre X X
NBS X
Prime X
Red Shark Software X
Schlumberger X
Sun X
Symbolics X X
Tectronix X X
Texas Instruments X X
Thinking Machines X X
Unisys X X
USC-ISI X
Wang X
Xerox X X
∂26-Jan-88 1143 FACIL-mailer Polya trade-in
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 88 11:43:33 PST
Date: Tue 26 Jan 88 11:39:09-PST
From: Thomas Dienstbier <TOM@Score.Stanford.EDU>
Subject: Polya trade-in
To: facil@Sail.Stanford.EDU
cc: nilsson@Score.Stanford.EDU, wheaton@athena.Stanford.EDU
Message-ID: <12369741442.13.TOM@Score.Stanford.EDU>
Disposition of Truffle.
As you all know, Truffle was one of the main trade-in computers towards
the acquisition of POLYA. I have just completed the acceptance of Truffle
from DEC. Yes, it has taken almost 2 years. March of 1986 is when the
donation was conceived..My gut-level-reaction to trading in Truffle was
that DEC would take it in trade-in (with trade-in credit associated) but,
would never actually pick it up. Well, since it has taken two years for DEC
to get it off of their books, they don't even want to talk about it coming
back. So, we keep the trade in credit and also get to keep the machine.
So what do we do with it?
It would be very easy for me at this time to support both Sushi and Score.
This would create some "free" accounts for students with the department paying
some fixed fee. Having an option for students on having unix cycles that
the department would have to pay more on or the fix rate of Sushi..
Or do we just want to forget that Truffle is indeed in storage on the
5th floor.
Selling Truffle in the open market would bring in around $5-6K..
tom
ps. I will work Sushi back into the CSDCF budget to see what it would look
like in the way of associated costs.
-------
∂26-Jan-88 1548 FACIL-mailer [John Sack <GQ.VVN@forsythe.stanford.edu>: The "whois" database]
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 88 15:48:16 PST
Date: Tue 26 Jan 88 15:38:07-PST
From: Stuart Reges <REGES@Score.Stanford.EDU>
Subject: [John Sack <GQ.VVN@forsythe.stanford.edu>: The "whois" database]
To: facil@Sail.Stanford.EDU
Office: CS-TAC 22, 723-9798
Message-ID: <12369784945.38.REGES@Score.Stanford.EDU>
I thought the following message would be of interest to the Facilities
Committee. It sounds like it might be better to try to influence what these
people are doing rather than try to create our own email forwarding. For
example, perhaps we should have our students/faculty/staff run their program
to change preferred email, and then we can copy the data from their machine
to put into LOOKUP (which also changes the formation of mailing lists
maintained by the department).
By the way, John Sack says that the 8-char truncation problem mentioned at
the meeting is, in fact, not a problem because, although 8-char truncation
is standard, FORSYTHE looks at all chars.
---------------
Return-Path: <GQ.VVN@forsythe.stanford.edu>
Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 26 Jan 88 08:54:38-PST
Received: by lindy.stanford.edu; Tue, 26 Jan 88 08:59:49 PST
Date: Tue, 26 Jan 88 08:58:19 PST
From: John Sack <GQ.VVN@forsythe.stanford.edu>
To: reges@score.stanford.edu
Subject: The "whois" database
JDN, JWS, CSB, Stuart,
fyi. you may have seen this before, since it is not exactly fresh,
but I wanted to be sure.
John
To: J. Nisbet(GG.JDN), J. Stosick(GG.JWS), C. Bennett(GD.CSB), REGES@SCORE
FORWARDED MESSAGE 01/26/88 07:20 FROM GD.WHY "Bill Yundt": The "whois" database
BILL....APPROPOS DIRECTORIES AND RELATIONSHIP WITH WHOIS
SERVICES...BILL
To: Bill Witscher(AU.WEW), John Sack(GQ.VVN), Ralph Gorin(G.GORIN@LOTS-A)
FORWARDED MESSAGE 12/14/87 16:08 FROM MORGAN@JESSICA.STANFORD.EDU: The "whois"
database
Received: by Forsythe.Stanford.EDU; Mon, 14 Dec 87 16:08:56 PST
Received: from jessica.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 14 Dec
87 16:03:02-PST
Received: by jessica.Stanford.EDU; Mon, 14 Dec 87 16:07:13 PST
To: nethax@jessica.Stanford.EDU, hostadmin@jessica.Stanford.EDU,
su-computers@score.stanford.edu
Cc: gg.jws@forsythe.stanford.edu
Subject: The "whois" database
Date: Mon, 14 Dec 87 16:07:08 -0800
From: morgan@jessica.Stanford.EDU
There have been some comments posted recently about the service
offered by the "whois" database. This note presents some
semi-official Networking points of view in an attempt to clear the air
a bit.
First, what is "whois"? The "whois" service that most people see is
a program on their host computer that fetches information from a
database on Argus, a MicroVAX maintained by Networking and
Communication Systems. This database contains records for all
networked host computers, workstations, and microcomputers on campus,
as well as network routers (gateways), Kinetics gateways, etc. It
also contains records for Stanford faculty, staff, and students.
Where does the "whois" information come from? The information on
network hosts and gateways is entered by Networking staff and by
local network administrators in various campus organizations. The
information is entered using the "NetDB" package on Jessica. The
NetDB database system, in addition to generating the database used
for "whois" service on Argus, generates many tables used for IP
routing, PUP routing, AppleTalk routing, host address tables, etc.
The information about staff and faculty comes from a variety of
sources, including Personnel and the Communication Services database
that produces the telephone directory. The student information comes
from the Network for Student Information maintained by the
Registrar's office, and from LOTS (for electronic mail address
information).
Assembling this information from such a wide variety of sources is a
difficult and time consuming task. Information Resources is
investigating ways of bringing its multiple electronic directories
into closer harmony, but for the moment the "whois" database cannot
be expected to be any more accurate or up-to-date than the published
telephone directory.
Student information in particular is difficult to keep accurate.
When it was decided, this fall, to remove last year's obsolete
student records, we did not expect that the delay in installing this
year's records would be as long as it has been. We regret we did not
inform "whois" users properly about this action. New records for all
registered students will be installed by the first day of the winter
quarter (January 5).
It is unfortunate that the one piece of information which many
"whois" users consider most useful in a person's record, the
electronic mail address, has been the most difficult to collect and
keep accurate (for students in particular). To address this problem,
Networking is now designing an interactive front-end to the "whois"
database to allow people to modify their own records in a fairly
secure way. We expect this service to be available in January.
One feature of the "whois" database that has received some attention
is its use in mail forwarding. A service is currently in place on
Argus to forward mail based on the "unique-id" and "e-mail-address"
parts of a person's record. Since Argus is aliased as "Stanford",
mail sent to "unique-id@Stanford.Edu" will be forwarded to a person's
preferred electronic mail address *if* that address is in the
person's "whois" record. Since student records have generally not
had accurate electronic mail addresses, this service has only been
supported for faculty and staff. Since even faculty and staff
electronic mail addresses have not been entirely accurate, this
service has been advertised on an "as is" basis only. The recent
enhancement of the Forsythe mail service to allow BitNet mail to be
addressed to "unique-id@Stanford" suffers from the same restriction.
With the addition of the facility described above, to allow people to
correct their own records, we believe this mail forwarding service
will become more useful. It will be extended to serve students at
that time.
The generation of a "unique-id" for a large population like Stanford
is a tricky problem. Attempting to accommodate such systems as
mailers with eight-character user-id limits makes it that much worse.
The current scheme makes use of the initials of a person's first and
middle names, their full last name, and a trailing digit if necessary
for uniqueness. We are happy to accept suggestions for better
algorithms for this purpose.
Comments on these topics may be sent to "networking@Jessica."
- RL "Bob" Morgan
Networking Systems
-------
∂26-Jan-88 1554 @Score.Stanford.EDU:VAVASIS@Sushi.Stanford.EDU students & polya
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 88 15:54:30 PST
Received: from Sushi.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 26 Jan 88 15:48:01-PST
Date: Tue 26 Jan 88 15:37:32-PST
From: Stephen Vavasis <VAVASIS@Sushi.Stanford.EDU>
Subject: students & polya
To: faculty@Score.Stanford.EDU
cc: bureaucrat@Sushi.Stanford.EDU
Message-ID: <12369784837.34.VAVASIS@Sushi.Stanford.EDU>
To the C.S. Dept. Faculty:
Today at the student meeting there was a discussion about the
question of computer access for students, and, specifically,
about the policy of paying for Polya. The students are apparently
unanimously in favor of:
o All PhD students in the department should have access to a computer.
From what I understand, the faculty also are in agreement with
this principle in general. However, I have heard (I am not
privy to what goes on the ``faculty@score'' mailing list) that
there are some faculty members (I don't know which ones)
who believe that:
o My research money should not go to pay for general PhD student
computer time.
My feeling is that this point of view is wrong. Faculty members
at Stanford have the privilege of being associated with a
prestigious department, and in return, they have an obligation
to support certain basic services. I cannot believe that a
computer science faculty member here thinks that computer
time for PhD students is not a basic service. A faculty member
who is dead set against sharing ought to leave Stanford and
start his own company, putting himself in a position to act
independently.
I've also heard that there are some faculty members who are
arguing:
o Government regulations prevent me from spending my
research money on general computing for students.
This, in my opinion, is a smokescreen. After all, Carnegie-
Mellon provides unlimited computing for students without
accounting. Clearly there is some way to bend the
rules and get around this problem.
Let me invite the faculty members to tell the students what they
think about polya. So far we have heard mainly from Nils
and other students.
-- Steve Vavasis
-------
∂26-Jan-88 1641 @Score.Stanford.EDU:dill@amadeus.stanford.edu polya
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 88 16:41:44 PST
Received: from amadeus.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 26 Jan 88 16:35:21-PST
Received: by amadeus.stanford.edu; Tue, 26 Jan 88 16:39:56 PST
Date: Tue, 26 Jan 88 16:39:56 PST
From: David Dill <dill@amadeus.stanford.edu>
Subject: polya
To: faculty@score.stanford.edu
I think that a substantial quantity of free computing should be
available to all PhD students, regardless of their affiliation with
research projects. If requested, I can elaborate on why I feel this
way. For now, I will assume that everyone thinks it would be nice
but that it costs too much.
I am very confused about the accounting issues involved here.
How much does it cost to provide student accounts? If the
students don't "use" all of the machine, who will use the
rest (and who will pay for it?) I have the impression from
talking to Stuart that student computing will be more expensive
on Polya than it has been on Sushi, which is counterintuitive.
Perhaps some way of providing student accounts has been overlooked.
∂26-Jan-88 2153 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Polya and Sushi
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 88 21:53:42 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 26 Jan 88 21:46:41-PST
Date: 26 Jan 88 2126 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Polya and Sushi
To: faculty@Score.Stanford.EDU
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 88 09:29:49 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 26 Jan 88 09:24:51-PST
Date: 26 Jan 88 0928 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Polya and Sushi
To: CSD@SAIL.Stanford.EDU, nilsson@SCORE.STANFORD.EDU, wheaton@ATHENA.Stanford.EDU
Below are some rambings that may shed some light on the Sushi to Polya
conversion debacle.
Pricing on Sushi was stable for the dept and for the students. The dept
picked up the fixed maintenance charges and the students had free accounts.
This encourages unlimited usage, since it is "free" or at least already
paid for.
Pricing on Polya is not stable, but in fact bi-stable. Essentially, all
costs of Polya are apportioned among its users based on amounts of usage.
If the rates (based on estimated usage) are set too high, no one will use
Polya, the rates will have to go up further, and it will suffer
cost-death. (Two big users are intentionally temporarily preventing Sail
from suffering cost-death.) If the rates for Polya are set low enough,
everyone will start using it, thereby enabling the rates to fall even
further, and the machine will become terribly overloaded.
Since Polya has a fixed overall operational cost (more or less), this cost
will be apportioned among the users. Government rules prevent us from
discriminatory pricing, since they are required to get the lowest rates
we provide to anyone (under the same conditions, of course). If we allow
unlimited student usage, it will swamp paying usage (look at the load on
Sushi these days), and departmental funds will wind up paying for more
of Polya than we paid for Sushi.
One main source for money for Sushi (and student computing on Polya) is
Computer Forum money. Please do support the Forum by participating and
sending in your resume. This money also goes to pay for TAs, as the
University is particularly chintzy on this. Our TA budget is three times
what the University provides us, and this supports MS students who could
otherwise be TAs, as well as providing better educational service. (Dare
I ask whether people prefer unlimited computing paid for by greatly
diminished TA support?) [This paragraph has been a public service
announcement.]
My understanding is that Sushi will not "go away" but instead will become
the hot spares machine for Score. That is, Sushi will effectively be
Truffle. The purchase of additional hardware will allow Sushi and Score
to share disks. This will allow Sushi to come online as Score with
minimal recabling when necessary. It will also Sushi users to pull their
files off with FTP when Sushi was acting as Score. I believe strongly
that we should do this. If you agree, send messages to the powers that be
(Jim Ball and Nils Nilsson) with your encouragement.
Sushi came into being because DARPA donated to Stanford CS a used DEC-20.
This "free" computer cost the department a lot of money. Perhaps the best
way of getting a UNIX equivalent of Sushi is to get someone to donate a
"free" UNIX machine with low maintenance costs.
Arthur
∂27-Jan-88 0915 ULLMAN@Score.Stanford.EDU Polya charges
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 88 09:15:42 PST
Date: Wed 27 Jan 88 09:10:08-PST
From: Jeffrey D. Ullman <ULLMAN@Score.Stanford.EDU>
Subject: Polya charges
To: faculty@Score.Stanford.EDU, ark@Sail.Stanford.EDU
Message-ID: <12369976458.37.ULLMAN@Score.Stanford.EDU>
When the idea of charging for services came on the scene, roughly
the same time I did, EAF had the right idea: charge for disk space,
but make cycles free. That way, both the department and the PI's
can predict in advance how much they are paying (you have to
place space-limits on accounts, of course). It also mitigates
against the cost-death and usage-death problems that ARK pointed out.
If I recollect, CPU usage and connect time tracked disk usage
pretty well, in all but a few extreme cases.
---jeff
-------
∂27-Jan-88 0926 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: Polya charges
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 88 09:26:39 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 27 Jan 88 09:20:46-PST
Date: 27 Jan 88 0925 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: Polya charges
To: ULLMAN@SCORE.Stanford.EDU, faculty@SCORE.Stanford.EDU
Actually, when Score and Sail first began to have usage charges on them,
people bought "aliquots" on them. These aliquots had fixed prices on them
and they represented the right to use a certain amount of disk space
in the form of disk quota, and use of CPU, etc. Some systems
enforce disk quotas more rigidly than others. SAIL, for example, uses
the PURGE approach to remove excess files on a periodic basis. Score
has continuous and instantaneous hard limits. I don't know how they
are enforced on UNIX. Do we want to track disk usage or disk allocations?
For some reason, we had to change that policy to more detailed bean counting.
Some considered it unfair. But I think it was the University's office
overseeing cost centers that made it go away. Betty Scott may know the
details, although I'm sure she'd rather forget them.
Arthur
∂27-Jan-88 1033 GOLDBERG@Score.Stanford.EDU POLYA
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 88 10:33:07 PST
Date: Wed 27 Jan 88 10:27:21-PST
From: Andrew Goldberg <GOLDBERG@Score.Stanford.EDU>
Subject: POLYA
To: faculty@Score.Stanford.EDU
Message-ID: <12369990515.41.GOLDBERG@Score.Stanford.EDU>
I do think that students have an option to get a SUSHI-like
account. Some limits may be needed to discourage students with
access to other machines from using this account.
What happens to SCORE and NAVAJO once POLYA is operational?
Can one of these machines be used for student accounts?
My understanding is that the current difficulty is due to the
higher cost of POLYA compared to SUSHI. If this is the case,
limiting student access to POLYA is not going to help.
Since POLYA is more powerful then SUSHI, there should be a way of
giving students the same amount of computing resources after the change
as they had before the change.
--Andrew
-------
∂27-Jan-88 1048 @Score.Stanford.EDU:kolk@polya
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 88 10:48:43 PST
Received: from polya by SCORE.STANFORD.EDU with TCP; Wed 27 Jan 88 10:43:01-PST
Received: by polya (5.54/inc-1.2)
id AA02723; Wed, 27 Jan 88 10:47:23 PST
Date: Wed, 27 Jan 88 10:47:23 PST
From: kolk@polya.stanford.edu (Dan Kolkowitz)
Message-Id: <8801271847.AA02723@polya>
To: faculty@score.stanford.edu
Hello,
We have the opportunity to become a beta site for release 4.0 of the
Sun operating system. There are a number of reasons that we'd like to
do this but the particular opportunity is based on our being especially
interested in the Lisp and Symbolic Programming Environments. I believe
that this is true. The questionairre that we must answer is listed
below. If you could help on the usage questions it would be greatly
appreciated. I will merge the responses so please send them to me.
Thanks, Dan
-----
Sun Common Lisp (SCLisp) 3.0
and
Symbolic Programming Environment (SPE) 1.0
BETA QUESTIONNAIRE
Sun will Beta test the Lisp 3.0 and SPE 1.0 products together at
overlapping times. Lisp 3.0 will be shipped to the beta sites
first (schedule for 12/16) with SPE 1.0 shipped approximately one
month later. The sites will have both products together for at
least six weeks of testing.
SCLisp 3.0 SUMMARY
------------------
SCLisp 3.0, the next Common Lisp release from Sun, will offer the
following enhancements:
- Generation Scavenger Garbage Collection, in pseudo real-time,
replaces the Stop and Copy style collection algorithm used in
prior releases. This algorithm, implemented in assembly
language for performance, will use less virtual memory.
- The Debugger has a better backtrace display, access to
local variables by name, and more command options.
- Multi-processing (Stack Groups) allows multiple Lisp
processes in the same image. Variables can be either
process-local or global. Process locks, events, and
communication are included.
- Floating Point support is in-line for the 68881 and FPA
on the Sun-3, and the Weitek chip set on the Sun-4.
- Window Manager, an implementation of Common Windows, is
built on NeWS.
SPE 1.0 Summary
---------------
SPE 1.0 provides Sun workstations with sophisticated program development
tools for artificial intelligence and symbolic programming. The tools
facilitate rapid prototyping so programmers can maximize their
productivity and reduce development time, all on a general purpose
workstation. The key features include:
- A special Emacs-style editor includes a set of Lisp libraries
and can handle several modes, such as running utilities as
well as editing Lisp code.
- The Common Lisp Window Manager, based on NeWS, provides a
toolkit of Lisp windowing functions.
- A runtime dynamic window-based Debugger gives information on
the state of the program.
- A window-based Data Inspector allows inspecting instances of
Lisp data structures.
- A window-based Single Stepper allows line-by-line execution of
Lisp Source code.
- A window-based Trace is a tool for monitoring the execution of
a function or set of functions during runtime.
- The Source Code Analyzer produces a set of relationships of
the functions which users can use to follow the flow of
control while editing the program.
- The Source Code Finder is a tool for locating specific source
for any function.
- The Application Manager keeps track of the dependencies of
of source file and functions involved in an application.
- A set of library functions that create important interfaces
between Lisp and UNIX so that the extensibility of the Sun
workstation and its networking tools can be fully integrated
with the symbolic application programs.
BETA SITE REQUIREMENTS
----------------------
The beta site must be willing to sign a testing agreement,
to do installs quickly (including updates and/or re-installs),
and to provide solid feedback in weekly written reports.
Under the no charge beta policy, Sun Customer Service
retains ownership of the product. The customer will not
be allowed to purchase the product before FCS.
SCLisp 3.0/SPE 1.0 Beta Requirements are as follows:
1) Must be running at least 3.4 Sun OS on a Sun-3.
2) Must have 12 Megabytes of memory
in the target machines.
3) Must have 40 Megabytes of disk space
on the machines on which Lisp/SPE/NeWS will
be installed.
4) Must have 40 Megabytes of disk swap space
available to Lisp and SPE.
BETA SITE INFORMATION
---------------------
*************************************************************
CONTACT NAME:
COMPANY NAME:
ADDRESS:
PHONE:
E-MAIL ADDRESS:
SUN SALES REP:
SUN TECH REP:
**************************************************************
Do you have a UUCP connection to Sun?
If so, what is the email address?
If not, do you have a UUCP connection to anyone?
Or can you set up a connection with your local Sun office?
What kind of support contracts do you have?
(hardware, software, unbundled software)
What release of Sun software (Unix) are you running?
Do you need 1/2 inch or 1/4 inch tapes? Or can either
size be used?
Do you have the hardware you plan to run on?
If so, list machine type and serial numbers.
How long have they had their equipment?
What is your hardware configuration?
(Include in the configuration any disks you have and network
configuration information.)
What kind of applications will Lisp be used for? Give
a detailed explanation. Does it already exist?
Will Lisp be included in a shipped product? What are the alpha and
beta schedules for that product? (Include only if this material is
non-confidential)
How many developers will be involved in the Lisp beta test?
Is there a deadline for a planned demonstration of the application?
What previous development experience do you have with Lisp software development?
Describe in detail.
What Sun Lisps do you have previous experience with? Explain if you purchased
the product or were a prior beta site.
What non-Lisp languages does the code interface to?
How do you plan to test success?
Have you been a beta site for other Sun products?
If so, which ones?
Can you characterize the areas of expertise of the development group?
MARKETING QUESTIONS:
Are you willing to participate in a press release which states
your support and endorsement of the Lisp product?
Can you cite contacts through which you could be influential in
promoting Common Lisp as a standard? (Standards committees, other companies,
consortiums)
∂27-Jan-88 1115 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: POLYA
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 88 11:15:08 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 27 Jan 88 11:05:57-PST
Date: 27 Jan 88 1039 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: POLYA
To: GOLDBERG@SCORE.Stanford.EDU, faculty@SCORE.Stanford.EDU
I wonder....
Is it possible to have the dept buy a fixed slice (cpu, disk, etc.) of
Polya and give it in an unlimited manner to the students? We could
get the slice size based on the ratio of the costs of Sushi to Polya.
Arthur
∂27-Jan-88 1427 REGES@Score.Stanford.EDU NExpert Object
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 88 14:27:53 PST
Date: Wed 27 Jan 88 14:21:36-PST
From: Stuart Reges <REGES@Score.Stanford.EDU>
Subject: NExpert Object
To: faculty@Score.Stanford.EDU
Office: CS-TAC 22, 723-9798
Message-ID: <12370033159.16.REGES@Score.Stanford.EDU>
This Friday from 10:30-12 the academic computing people will be meeting with
representatives from Neuron Data who have created an object-oriented expert
system for Mac II's and other unix workstations running X windows. If anyone
is interested in attending, let me know and I'll send you the details. The
academic computing people seem to be welcoming skeptical people who might ask
difficult questions.
-------
∂27-Jan-88 1647 @Score.Stanford.EDU:pratt@chehalis Re: NExpert Object
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 88 16:47:22 PST
Received: from chehalis.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 27 Jan 88 16:41:33-PST
Received: by chehalis.stanford.edu (3.2/SMI-DDN)
id AA19263; Wed, 27 Jan 88 16:22:01 PST
Message-Id: <8801280022.AA19263@chehalis.stanford.edu>
To: Stuart Reges <REGES@score.stanford.edu>
Cc: faculty@score.stanford.edu
Subject: Re: NExpert Object
In-Reply-To: Your message of Wed 27 Jan 88 14:21:36-PST.
<12370033159.16.REGES@Score.Stanford.EDU>
Date: 27 Jan 88 16:21:57 PST (Wed)
From: pratt@chehalis
an object-oriented expert
system for Mac II's
Sounds interesting. Would this be something Stanford could fit
into its ethernet-oriented environment? Would it have ftp or rcp and
telnet or rlogin? Can file systems be mounted remotely? What
do Mac II's with a usably-sized screen cost Stanford? Or are these
questions for ACIS and/or Neuron Data?
-v
∂27-Jan-88 1748 emma@alan.stanford.edu CSLI Calendar, January 28, 3:15
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 27 Jan 88 17:48:34 PST
Received: from alan.stanford.edu by russell.stanford.edu (3.2/4.7); Wed, 27 Jan 88 17:07:32 PST
Received: by alan.stanford.edu (3.2/4.7); Wed, 27 Jan 88 17:08:31 PST
Date: Wed, 27 Jan 88 17:08:31 PST
From: emma@alan.stanford.edu (Emma Pease)
To: friends@alan.stanford.edu
Subject: CSLI Calendar, January 28, 3:15
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
28 January 1988 Stanford Vol. 3, No. 15
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 28 January 1988
12 noon TINLunch
Ventura Hall Reading: "True Believers: The Intentional
Conference Room Strategy and Why it Works"
by Daniel Dennett
Discussion led by Adrian Cussins
(cussins.pa@xerox.com)
Abstract in last week's Calendar
2:15 p.m. CSLI Seminar
Room G-19 Modal Subordination, Situations, and Reference Time
Redwood Hall Craige Roberts
(croberts@csli.stanford.edu)
Abstract in last week's Calendar
3:30 p.m. Tea
Ventura Hall
--------------
CSLI ACTIVITIES FOR NEXT THURSDAY, 4 February 1988
12 noon TINLunch
Ventura Hall Reading: "Some Uses of Higher-Order Logic
Conference Room in Computational Linguistics"
by Dale A. Miller and Gopalan Nadathur
Discussion led by Douglas Edwards
(edwards@warbucks.ai.sri.com)
Abstract below
2:15 p.m. CSLI Seminar
Room G-19 A Nonmonotonic Account of Causation
Redwood Hall Yoav Shoham
(shoham@score.stanford.edu)
Abstract below
3:30 p.m. Tea
Ventura Hall
--------------
NEXT WEEK'S TINLUNCH
Reading: "Some Uses of Higher-Order Logic
in Computational Linguistics"
by Dale A. Miller and Gopalan Nadathur
from "24th Annual Meeting of the Association for Computational
Linguistics: Proceedings of the Conference" (1986)
Discussion led by Douglas Edwards
(edwards@warbucks.ai.sri.com)
4 February 1988
Miller and Nadathur present a system of higher-order logic (typed
lambda-calculus) as a suitable formalism for the representation of
syntactic and semantic information in computational linguistics. They
argue that such a formalism is clearer and more natural than available
alternatives. They also reply point by point to certain standard
criticisms of the computational use of higher-order logic. In
particular, they argue that:
(1) Theoretical linguistics is often heavily committed to higher-order
logic anyway (Montague Semantics, for example) and it will be
easier to design working systems to fit a theory if the
computational formalism mirrors the ontology of the theory.
(2) Even if a first-order formalism is used to represent the semantics
of sentences, *reasoning* about semantics is an inherently
higher-order process and cannot be represented with full
naturalness in the same formalism. This fact leads to the use of
ad hoc procedures for semantics and to the development of separate
semantic and syntactic formalisms. The use of higher-order logic
allows easier integration of semantic and syntactic processing.
(3) The formalization of semantic processing in first-order formalisms
like Prolog is bedevilled by the need to consider explicitly the
intricate processes of substitution and variable binding. A logic
programming language for higher-order logic, like Miller and
Nadathur's LambdaProlog, obviates this need through the use of
beta-conversion in the language itself.
(4) The difficulty of theorem-proving in higher-order logic is evaded
by confining attention to a restricted set of formulas (analogous
to Horn clauses in first-order logic) and lowering sights from
full theorem-proving to logic programming, using a highly
restricted proof procedure. If more is needed, restricted
theorem-provers can easily be designed *within* LambdaProlog.
It would also appear that much ordinary reasoning even outside of
linguistic semantics is higher-order. Are Miller and Nadathur right
in thinking that their formalism can help to bridge the gap between
linguistic theory and computational practice?
--------------
NEXT WEEK'S SEMINAR
A Nonmonotonic Account of Causation
Yoav Shoham
(shoham@score.stanford.edu)
4 February 1988
We suggest that taking into account considerations that traditionally
fall within the scope of computer science in general, and artificial
intelligence in particular, may shed light on the concept of
causation. We argue that causal reasoning is a mechanism for making
coarse, but fairly reliable, inferences in the absence of full
information. Specifically, we propose that the concept of causation is
intimately bound to that of nonmonotonic reasoning. We offer an
account of causation which relies on this connection, and briefly
compare our proposal to previous accounts of causation within
philosophy.
∂27-Jan-88 2226 LOGMTC-mailer Logic seminar
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 27 Jan 88 22:26:15 PST
Received: by russell.stanford.edu (3.2/4.7); Wed, 27 Jan 88 22:29:25 PST
Date: Wed 27 Jan 88 22:29:22-PST
From: Sol Feferman <SF@Russell.Stanford.EDU>
Subject: Logic seminar
To: logic@russell.stanford.edu
Message-Id: <570349762.0.SF@Russell.Stanford.EDU>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@Russell.Stanford.EDU>
Speaker: Luca Cardelli, Digital Equipment Corp., Systems Research Ctr.
Title: Subtyping, from languages to type systems
Time: Tuesday, Feb.2, 4:15-5:30
Place: Room 381-T, Math Corner, Stanford
S. Feferman
Abstract
As programming language features grow more powerful and complex,type theory helps organizing and clarifying them. Conversely, modern
programming languages require very advanced type systems, at the
frontiers of constructive logic.
In this talk we focus on a specific notion of subtyping, how it arises
from programming languages, and how it can be formalized in type systems.
In its most general formulation, it is embedded in an impredicative
higher-order lambda-calculus.
L. Cardelli
-------
∂28-Jan-88 1028 @Score.Stanford.EDU:cheriton@Pescadero.stanford.edu Re: Any interest in the B & H Film Recoder
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Jan 88 10:28:36 PST
Received: from Pescadero by SCORE.STANFORD.EDU with TCP; Thu 28 Jan 88 10:19:22-PST
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA01474; Thu, 28 Jan 88 10:23:53 PST
Date: Thu, 28 Jan 88 10:23:53 PST
From: "David Cheriton" <cheriton@pescadero.stanford.edu>
Message-Id: <8801281823.AA01474@Pescadero>
To: FACULTY@score.stanford.edu, ball@navajo.stanford.edu
Subject: Re: Any interest in the B & H Film Recoder
If "standalone" really means not connected to the network, we should definitely
not do this. I suggest that CSD-CF get the commands-level doc. from B&H
and connect it to a reasonable machine. Then, maybe we can get some student
to write a dvi to B&H filter as a programming project. Barring that, this
stuff sounds like landfill.
∂28-Jan-88 1108 FACIL-mailer Re: Polya trade-in
Received: from Pescadero (Pescadero.Stanford.EDU) by SAIL.Stanford.EDU with TCP; 28 Jan 88 11:08:39 PST
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA02488; Thu, 28 Jan 88 11:08:29 PST
Date: Thu, 28 Jan 88 11:08:29 PST
From: "David Cheriton" <cheriton@pescadero.stanford.edu>
Message-Id: <8801281908.AA02488@Pescadero>
To: TOM@score.stanford.edu, facil@sail.stanford.edu
Subject: Re: Polya trade-in
Cc: nilsson@score.stanford.edu, wheaton@athena.stanford.edu
Let's get rid of this old junk. Going to Polya was supposed to reduce our
costs and our dependence on 20's. We op'ed for a cure so let's take all
the medicine.
∂28-Jan-88 1202 @Score.Stanford.EDU:coraki!pratt@Sun.COM Any interest in the B & H Film Recoder
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Jan 88 12:02:32 PST
Received: from Sun.COM by SCORE.STANFORD.EDU with TCP; Thu 28 Jan 88 11:54:54-PST
Received: from sun.Sun.COM ([129.144.1.3]) by Sun.COM (4.0/SMI-3.2)
id AA01083; Thu, 28 Jan 88 12:00:02 PST
Received: from coraki.UUCP by sun.Sun.COM (4.0/SMI-4.0)
id AA23290; Thu, 28 Jan 88 12:01:54 PST
Received: by (4.0/SMI-4.0Beta)
id AA12896; Thu, 28 Jan 88 11:58:20 PST
Date: Thu, 28 Jan 88 11:58:20 PST
From: coraki!pratt@Sun.COM (Vaughan Pratt)
Message-Id: <8801281958.AA12896@>
To: ball@navajo.stanford.edu, faculty@score.stanford.edu
Subject: Any interest in the B & H Film Recoder
From: "David Cheriton" <sun!pescadero.stanford.edu!cheriton>
maybe we can get some student
to write a dvi to B&H filter as a programming project.
yielding about 2 orders of magnitude below what you would get from
sending your work out for professional production by Genigraphics.
I have enough software to get to within 1/2 an order of Genigraphics
quality if it gets hooked up to the net; rasterfile to B&H is the
proper abstraction here.
-v
∂28-Jan-88 1418 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com Planlunch NEXT WEDNESDAY -- Yishai Feldman
Received: from WARBUCKS.AI.SRI.COM by SAIL.Stanford.EDU with TCP; 28 Jan 88 14:18:21 PST
Received: from venice by WARBUCKS.AI.SRI.COM via SMTP with TCP; Thu,
28 Jan 88 13:19:42-PST
Received: by venice (3.2/4.16) id AA15176 for planlunch@ai.sri.com;
Thu, 28 Jan 88 12:23:33 PST
Date: Thu, 28 Jan 88 12:23:33 PST
From: Amy Lansky <lansky@venice.ai.sri.com>
Message-Id: <8801282023.AA15176@venice>
To: planlunch@ai.sri.com
Subject: Planlunch NEXT WEDNESDAY -- Yishai Feldman
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
BREAD, FRAPPE, AND CAKE:
THE GOURMET'S GUIDE TO AUTOMATED DEDUCTION
Yishai A. Feldman (YISHAI@AI.AI.MIT.EDU)
AI Laboratory, MIT
11:00 AM, WEDNESDAY, February 3
SRI International, Building E, Room EJ228
Cake is the knowledge representation and reasoning system developed as
part of the Programmer's Apprentice project. Cake can be thought of
as an active database, which performs quick and shallow deduction
automatically; it supports both forward-chaining and backward-chaining
reasoning. The Cake system has a layered architecture: the kernel of
the system, called Bread (for Basic REAsoning Device), is a
truth-maintenance system with equality and demons. Built on top of
this is Frappe (for FRAmes in a ProPositional Engine), which
implements a typed logic with special-purpose decision procedures for
various algebraic properties of operators (such as commutativity and
associativity), sets, partial functions, and structured objects
(frames). Only the topmost layer of Cake, which implements the Plan
Calculus, is specific to reasoning about programs. This talk will
describe the architecture and features of Bread, Frappe, and Cake,
including a transcript of a demonstration session. This is joint work
with Charles Rich.
∂28-Jan-88 1659 hilbert@alan.stanford.edu Internships lunch
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 28 Jan 88 16:59:06 PST
Received: from alan.stanford.edu by russell.stanford.edu (3.2/4.7); Thu, 28 Jan 88 17:00:55 PST
Received: by alan.stanford.edu (3.2/4.7); Thu, 28 Jan 88 17:01:51 PST
Date: Thu 28 Jan 88 17:01:49-PST
From: Dave Hilbert <HILBERT@Alan.Stanford.EDU>
Subject: Internships lunch
To: ssp-faculty@alan.stanford.edu
Message-Id: <570416509.0.HILBERT@Alan.Stanford.EDU>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@Alan.Stanford.EDU>
We have tentatively scheduled the lunch for faculty and students
interested in the CSLI internships for Tuesday, February 9 at 12:00.
As I mentioned in my previous message the purpose of the lunch is to
bring together students interested in the internship program with
faculty interested in supervising interns to discuss possible
projects.
Please let me know if plan to attend or if you would like to attend
but cannot come that day. I will announce a location when we have a
better idea of how many people to expect. We will provide soft drinks
and cookies but you will have to bring your own lunch.
Dave Hilbert
Program Coordinator
-------
∂28-Jan-88 1825 ames!pyramid!tub!coma!mihalis@ucbvax.berkeley.edu PODS88 Program
Received: from navajo.stanford.edu by SAIL.Stanford.EDU with TCP; 28 Jan 88 18:25:45 PST
Received: from RUTGERS.EDU by navajo.stanford.edu with TCP; Thu, 28 Jan 88 18:17:26 PST
Received: by rutgers.edu (5.54/1.15) with UUCP
id AA10022; Thu, 28 Jan 88 15:00:27 EST
Date: Thu, 28 Jan 88 15:00:27 EST
From: ames!pyramid!tub!coma!mihalis@ucbvax.berkeley.edu
Message-Id: <8801282000.AA10022@rutgers.edu>
Received: by mtune.ATT.COM (smail2.5)
id AA21015; 28 Jan 88 14:51:11 EST (Thu)
To: nail@navajo.stanford.edu
Subject: PODS88 Program
Seventh ACM SIGACT-SIGMOD-SIGART Symposium
on
PRINCIPLES OF DATABASE SYSTEMS
Austin, Texas, March 21-23, 1988
INFORMATION
LOCATION
The 7th ACM Symposium on Principles of Database Systems will be held at
The Driskill, situated in downtown Austin in the heart of the entertainment
district. The Driskill Hotel, a Historical Landmark, combines 19th-century
atmosphere with 20th-century amenities.
Checkout time is noon; checkin time is 3pm, or earlier subject to
room availability. A block of rooms has been reserved until March 5th, 1988.
Please reserve a room by using the form provided or by calling 800-252-9367.
Room rates and availability are not guaranteed past March 5th.
REGISTRATION
Advanced registration is requested using the form provided. Registration rates
go up markedly after March 8th. A registration desk will be open Sunday
night from 7:30pm to 10:00pm, and during the day on Monday (8:30 am to 4:30 pm).
Registrants, other than students, receive admission to the technical sessions,
one copy of the proceedings, reception, lunches, and a Texas Barbeque on Tuesday
evening. Student registration, available to full-time students only, includes
the technical sessions and one copy of the proceedings. Additional copies of
the proceedings will be available for sale at the registration desk.
TRANSPORTATION
There are two choices for ground transportation from the airport to the hotel.
The Driskill provides complimentary airport transportation, which can be
summoned by a dedicated phone in the airport terminal or greeted personally if
arrival times are provided. Additionally, taxi fare to the hotel is about $5.
For participants driving to The Driskill, take IH35 south, then exit at
6th St. heading west. Valet parking is available at the main entrance at
604 Brazos, between 6th and 7th Streets.
CLIMATE
Normal daily temperatures in Austin in March range from 58 to 79 degrees F.
Measurable rain, usually in the form of thundershowers, can be expected on one
day in four. Occasional cold fronts bring northerly winds and sharp drops in
temperature, but cold spells seldom last more than two days. Expect to see most
trees and flowers in bloom.
EVENT LOCATION
All technical sessions, reception, lunches, and business meeting will be held
off the Mezzanine of The Driskill Hotel. On Tuesday night
there will be an excursion to find authentic Texas Barbeque. Buses will leave
the hotel at 6pm and return by 9pm.
------------------------------------------------------------------------------
TECHNICAL PROGRAM
SUNDAY, MARCH 20, 1988
Reception: 7:30 pm - 10:00 pm, Mezzanine
MONDAY, MARCH 21, 1988
Note: All talks will take place in the Crystal Ballroom
SESSION 1: 9:00 am - 10:30 am
Chair: Mihalis Yannakakis (AT&T Bell Laboratories)
Invited Talk: Theory of Database Queries,
Ashok K. Chandra (IBM T. J. Watson Research Center)
On the Expressive Power of Logic Programming Languages with Sets,
Gabriel M. Kuper (IBM T.J. Watson Research Center)
Rewriting of Rules Containing Set Terms in a Logic Data Language (LDL),
Oded Shmueli, Shalom Tsur and Carlo Zaniolo (MCC)
Coffee Break: 10:30 am - 11:00 am
SESSION 2: 11:00 am - 12:30 pm
Chair: Ronald Fagin (IBM Almaden Research Center)
Possibilities and Limitations of Using Flat Operators
in Nested Algebra Expressions, Jan Paredaens (University of Antwerp)
and Dirk Van Gucht (Indiana University)
On the Expressive Power of Database Queries with Intermediate Types,
Richard Hull and Jianwen Su (University of Southern California)
An Axiomatic Approach to Deciding Query Safety in Deductive Databases,
Michael Kifer (SUNY at Stony Brook), Raghu Ramakrishnan (University of
Wisconsin-Madison), and Avi Silberschatz (University of Texas at Austin)
Temporal Deductive Databases and Infinite Objects,
Jan Chomicki and Tomasz Imielinski (Rutgers University)
Lunch: 12:30 pm - 2:00 pm
SESSION 3: 2:00 pm - 3:30 pm
Chair: Alberto Mendelzon (University of Toronto)
The Complexity of Ordering Subgoals,
Jeffrey D. Ullman (Stanford University)
and Moshe Y. Vardi (IBM Almaden Research Center)
An Algorithm for Ordering Subgoals in NAIL!,
Katherine A. Morris (Stanford University)
Optimizing Existential Datalog Queries,
Raghu Ramakrishnan (University of Wisconsin-Madison),
Catriel Beeri (Hebrew University and MCC), and Ravi Krishnamurthy (MCC)
Explicit Control of Logic Programs Through Rule Algebra,
Tomasz Imielinski (Rutgers University) and Shamim Naqvi (MCC)
Coffee Break: 3:30 pm - 4:00 pm
SESSION 4: 4:00 pm - 5:30 pm
Chair: Henry Korth (University of Texas at Austin)
Analysis of Bounded Disorder File Organization,
M. V. Ramakrishna and P. Mukhopadhyay (Michigan State University)
Analytical Modeling of Materialized View Maintenance,
Jaideep Srivastava and Doron Rotem (University of California, Berkeley)
Serialization Graph Algorithms for Multiversion Concurrency Control,
Thanasis Hadzilacos (CTI Patras)
The Queue Protocol: a Deadlock-Free, Homogeneous, Non-Two-Phase Locking Protocol,
Udo Kelter (University of Dortmund)
Business Meeting: 8:30 pm - 10:00 pm, Mezzanine
TUESDAY, MARCH 22, 1988
SESSION 5: 9:00 pm - 10:30 pm
Chair: Victor Vianu (University of California, San Diego)
Invited Talk: Object-Oriented Database Systems,
Francois Bancilhon (INRIA)
Independence-Reducible Database Schemes,
Edward P. F. Chan (University of Waterloo),
and Hector J. Hernandez (Texas A&M University)
Decomposition of Relational Schemata into Components Defined
by Both Projection and Restriction,
Stephen J. Hegner (University of Vermont)
Coffee Break: 10:30 am - 11:00 am
SESSION 6: 11:00 am - 12:30 pm
Chair: Daniel J. Rosenkrantz (SUNY at Albany)
Concepts for a Database System Synthesizer,
D. S. Batory (University of Texas at Austin)
Transaction Synchronisation in Object Bases,
Thanasis Hadzilacos (CTI Patras) and Vassos Hadzilacos (University of Toronto)
Hybrid Concurrency Control for Abstract Data Types,
Maurice P. Herlihy (Carnegie Mellon University) and William E. Weihl (MIT)
Concurrent Set Manipulation without Locking,
Vladimir Lanin and Dennis Shasha (New York University)
Lunch: 12:30 pm - 2:00 pm
SESSION 7: 2:00 pm - 3:30 pm
Chair: Krzysztof Apt (CWI Amsterdam and University of Texas at Austin)
Unfounded Sets and Well-founded Semantics for General Logic Programs,
Allen Van Gelder (University of California at Santa Cruz),
and Kenneth Ross (Stanford University)
Why not Negation by Fixpoint?,
Phokion G. Kolaitis (Stanford University),
and Christos H. Papadimitriou (University of California, San Diego)
Procedural and Declarative Database Update Languages,
Serge Abiteboul (INRIA) and Victor Vianu (University of California, San Diego)
Database Updates in Logic Programming,
Shamim Naqvi and Ravi Krishnamurthy (MCC)
Coffee Break: 3:30 pm - 4:00 pm
SESSION 8: 4:00 pm - 5:30 pm
Chair: Avi Silberschatz (University of Texas at Austin)
Optimization of Multiple-Relation Multiple-Disjunct Queries,
M. Muralikrishna and David J. De Witt (University of Wisconsin, Madison)
Statistical Estimators for Relational Algebra Expressions,
Wen-Chi Hou, Gultekin Ozsoyoglu and Baldeo K. Taneja
(Case Western Reserve University)
Stable Set and Multiset Operations in Optimal Time and Space,
Bing-Chao Huang and Michael A. Langston (Washington State University)
Minimizing Time-Space Cost for Database Version Control,
Lin Yu and Daniel J. Rosenkrantz (SUNY at Albany)
Texas Barbeque: 6 pm - 9 pm
Meet the buses in the lobby
WEDNESDAY, MARCH 23, 1988
SESSION 9: 9:00 am - 10:30 am
Chair: Serge Abiteboul (INRIA)
Invited Talk: What Should a Database Know?,
Raymond Reiter (University of Toronto)
A Semantics for Complex Objects and Approximate Queries,
Peter Buneman, Susan Davidson and Aaron Watters (University of Pennsylvania)
A Framework for Comparison of Update Semantics,
Marianne Winslett (Stanford University)
Coffee Break: 10:30 am - 11:00 am
SESSION 10: 11:00 am - 12:10 pm
Chair: Paris Kanellakis (Brown University)
A Generalized Transitive Closure for Relational Queries,
Seppo Sippu (University of Jyvaskyla)
and Eljas Soisalon-Soininen (University of Helsinki)
Counting Methods for Cyclic Relations,
Ramsey W. Haddad (Stanford University)
and Jeffrey F. Naughton (Princeton University)
Decidability and Undecidability Results for Boundedness
of Linear Recursive Queries,
Moshe Y. Vardi (IBM Almaden Research Center)
-------------------------------------------------------------------------------
CONFERENCE ORGANIZATION
Sponsors: SIGACT, SIGMOD, and SIGART
Executive Committee: A. K. Chandra, A. Silberschatz, M. Y. Vardi, M. Yannakakis
Chairman: Avi Silberschatz, Dept. of Computer Sciences,
University of Texas at Austin, Austin, Texas 78712,
(512) 471-9706, avi@sally.utexas.edu
Program Chairman: Mihalis Yannakakis, AT&T Bell Laboratories,
600 Mountain Avenue, Murray Hill, NJ 07974,
(201) 582-2198, mihalis@research.att.com
Local Arrangements: Chris Edmondson-Yurkanan, Dept. of Computer Sciences,
University of Texas at Austin, Austin, Texas 78712,
(512) 471-9546, dragon@sally.utexas.edu
Program Committee: S. Abiteboul, K. Apt, P. Bernstein, P. Kanellakis,
D. Maier, A. Mendelzon, D. Skeen, V. Vianu, M. Yannakakis
-------------------------------------------------------------------------------
ADVANCE REGISTRATION FORM, ACM-PODS
Please send this form or a facsimile along with a money order or check
(payable to 7th ACM SYMPOSIUM ON PRINCIPLES OF DATABASE SYSTEMS) to:
ACM-PODS Registration
c/o Chris Edmondson-Yurkanan
Dept. of Computer Sciences
Taylor Hall 2.124
University of Texas at Austin
Austin, Texas 78712-1188
(before Mar. 8) (After)
ACM and SIG member $180 $240
ACM member only 190 250
SIG member only 190 250
Nonmember 225 290
Student 50 60
Requests for refunds will be honored until March 8, 1988.
Name_____________________________________________________
Affiliation______________________________________________
City_____________________State______________Zip__________
Country_______________________Telephone__________________
Net Address______________________________________________
_____ Check here if confirmation of registration is required.
Dietary restrictions: _______Kosher _______Vegetarian
Special meals can be guaranteed only for those who register in advance.
_______________________________________________________________________
HOTEL RESERVATION FORM, ACM-PODS March 1988
Please mail this form or a facsimile (being sure to mention the ACM-PODS
Conference) by March 5 to:
The Driskill
604 Brazos
Austin, Texas 78701
Tel: (512) 474-5911
or (800) 252-9367
Accomodations desired:
_____Single $55
_____Double $60
_____Triple $60
_____Quad $60
Arrival date_____________________________________Time__________________________
Departure date___________________________________Time__________________________
Name___________________________________________________________________________
Sharing room with______________________________________________________________
Address________________________________________________________________________
City_______________________________State__________________Zip__________________
Country________________________________________________________________________
All rooms will be held until 4pm the day of arrival without deposit/guarantee.
For arrivals later than 4pm please guarantee to a major credit card:
_____Amer. Express _____VISA _____Mastercard _____Diners _____Discover
Credit Card number____________________________________________________________
Exp. Date_____________________________________________________________________
Signature_____________________________________________________________________
______________________________________________________________________________
∂29-Jan-88 1237 RICE@SUMEX-AIM.Stanford.EDU A big thankyou...
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Jan 88 12:37:47 PST
Date: Fri, 29 Jan 88 12:34:59 PST
From: James Rice <Rice@SUMEX-AIM.Stanford.EDU>
Subject: A big thankyou...
To: AAP@SUMEX-AIM.Stanford.EDU, Rogers@SUMEX-AIM.Stanford.EDU
Message-ID: <12370538039.64.RICE@SUMEX-AIM.Stanford.EDU>
... to all of you who put so much effort into helping
me to get that SuperComputing paper out of the door.
All of your labours were much appreciated.
Rice.
-------
∂31-Jan-88 1426 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talk
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 31 Jan 88 14:25:58 PST
Date: Sun 31 Jan 88 14:19:58-PST
From: Anil R. Gangolli <GANGOLLI@Sushi.Stanford.EDU>
Subject: Upcoming AFLB Talk
To: aflb.all@Sushi.Stanford.EDU
Office Phone: (415) 723-3605
Message-ID: <12371081437.11.GANGOLLI@Sushi.Stanford.EDU>
PLEASE NOTE:
* The Mar. 3 slot is still open. If you would like to speak,
please contact me (gangolli@sushi.stanford.edu).
THIS WEEK'S TALK:
4-February-1988: Nir Shavit
Toward a Non-Atomic Era:
L-Exclusion as a Test Case
Most of the research in concurrency control has been based on the
existence of strong synchronization primitives such as test and set.
Following Lamport, recent research promoting the use of weaker
``safe'' rather then ``atomic'' primitives has resulted in
construction of atomic registers from safe ones, in the belief that
they would be useful tools for process synchronization. It has been
shown that using such atomic registers it is impossible to create
strong synchronization primitives such as test and set. We therefore
advocate a different approach, to skip the intermediate step of
achieving atomicity, and solve problems directly from safe registers.
We show how to achieve a fair solution to $\ell$-exclusion, a problem
previously solved assuming a very powerful form of test and set. We
do so using safe registers alone and without introducing atomicity.
The solution is based on the construction of simple novel
synchronization primitives that are non-atomic.
*** Time and Place: 12:30pm, Th, Feb. 4, Margaret Jacks Hall (MJH), Room 352
-------
∂01-Feb-88 1002 RICHARDSON@Score.Stanford.EDU Faculty Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 88 10:02:35 PST
Date: Mon 1 Feb 88 09:56:34-PST
From: Anne Richardson <RICHARDSON@Score.Stanford.EDU>
Subject: Faculty Lunch
To: faculty@Score.Stanford.EDU
Message-ID: <12371295631.31.RICHARDSON@Score.Stanford.EDU>
There will be the usual faculty lunch in MJH 146 at 12:00. The CSD Visiting
Committee will also be in attendance. There will be presentations on CSD
undergraduate and graduate programs. Please plan to attend if you can.
Heidi
-------
∂01-Feb-88 1511 X3J13-mailer Don't forget mailings
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 88 15:11:15 PST
Received: by labrea.Stanford.EDU; Mon, 1 Feb 88 15:11:29 PST
Received: from sunvalleymall.lucid.com by edsel id AA13089g; Mon, 1 Feb 88 14:55:21 PST
Received: by sunvalleymall id AA09790g; Mon, 1 Feb 88 14:59:40 PST
Date: Mon, 1 Feb 88 14:59:40 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8802012259.AA09790@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: Don't forget mailings
Documents for X3J13 should be mailed this week in order to reach
committee members on time. If you need mailing lables please
contact Bob Mathis.
---jan---
∂02-Feb-88 0944 @Score.Stanford.EDU:coraki!pratt@Sun.COM Document standard
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 88 09:44:29 PST
Received: from Sun.COM by SCORE.STANFORD.EDU with TCP; Tue 2 Feb 88 09:38:19-PST
Received: from sun.Sun.COM ([129.144.1.3]) by Sun.COM (4.0/SMI-3.2)
id AA18228; Tue, 2 Feb 88 09:43:34 PST
Received: from coraki.UUCP by sun.Sun.COM (4.0/SMI-4.0)
id AA01024; Tue, 2 Feb 88 09:43:33 PST
Received: by (4.0/SMI-4.0Beta)
id AA18384; Tue, 2 Feb 88 09:27:28 PST
Date: Tue, 2 Feb 88 09:27:28 PST
From: coraki!pratt@Sun.COM (Vaughan Pratt)
Message-Id: <8802021727.AA18384@>
To: faculty@score.stanford.edu
Subject: Document standard
I'd like to recommend that the department select a standard document
formatting language. When I arrived at Stanford I was all in favor of
Scribe, but the department seemed more interested in TeX. So I went to
the trouble of learning TeX and converting all my documents into TeX.
I can now cope with TeX with no problem.
In the meantime my Scribe capability has atrophied to the point where
the machines I use at both home and school no longer even have a Scribe
capability.
Last night I received the agenda for the visiting committee in Scribe.
This turnabout caught me completely by surprise.
Can we please settle on one or another? I don't care what it is, but
we should make up our minds about it and stick with it. If we were
continuing to do research into formatting languages a case could be
made for continuing to experiment, but we aren't and it can't. The
advantages of maintaining several formatting systems are more than
offset by the cost of maintaining them all. Software maintenance is
more of a headache today than ever, as the CSD-CF people will be
happy to relate to you in gory detail.
-v
∂02-Feb-88 1552 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com REMINDER -- Wednesday PLANLUNCH
Received: from WARBUCKS.AI.SRI.COM by SAIL.Stanford.EDU with TCP; 2 Feb 88 15:52:00 PST
Received: from venice by WARBUCKS.AI.SRI.COM via SMTP with TCP; Tue,
2 Feb 88 15:34:47-PST
Received: by venice (3.2/4.16) id AA19222 for
planlunch_reminder@ai.sri.com; Tue, 2 Feb 88 15:33:45 PST
Date: Tue, 2 Feb 88 15:33:45 PST
From: Amy Lansky <lansky@venice.ai.sri.com>
Message-Id: <8802022333.AA19222@venice>
To: planlunch_reminder@ai.sri.com
Subject: REMINDER -- Wednesday PLANLUNCH
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
BREAD, FRAPPE, AND CAKE:
THE GOURMET'S GUIDE TO AUTOMATED DEDUCTION
Yishai A. Feldman (YISHAI@AI.AI.MIT.EDU)
AI Laboratory, MIT
11:00 AM, WEDNESDAY, February 3
SRI International, Building E, Room EJ228
Cake is the knowledge representation and reasoning system developed as
part of the Programmer's Apprentice project. Cake can be thought of
as an active database, which performs quick and shallow deduction
automatically; it supports both forward-chaining and backward-chaining
reasoning. The Cake system has a layered architecture: the kernel of
the system, called Bread (for Basic REAsoning Device), is a
truth-maintenance system with equality and demons. Built on top of
this is Frappe (for FRAmes in a ProPositional Engine), which
implements a typed logic with special-purpose decision procedures for
various algebraic properties of operators (such as commutativity and
associativity), sets, partial functions, and structured objects
(frames). Only the topmost layer of Cake, which implements the Plan
Calculus, is specific to reasoning about programs. This talk will
describe the architecture and features of Bread, Frappe, and Cake,
including a transcript of a demonstration session. This is joint work
with Charles Rich.
∂02-Feb-88 1746 TAJNAI@Score.Stanford.EDU Statistics on Foreign Students
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 88 17:46:47 PST
Date: Tue 2 Feb 88 17:41:08-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Statistics on Foreign Students
To: faculty@Score.Stanford.EDU
cc: aho@Score.Stanford.EDU
Message-ID: <12371642347.29.TAJNAI@Score.Stanford.EDU>
Sharon Hemenway was very quick to get the statistics, but I still have
not heard from EE. However, the CS figures for foreign students are:
40% PHD
30% MS
54% MSAI
(I remember the PHD figure was 18% 10 years ago.)
The Visiting Committee was interested in these figures, so please
pass them on.
Carolyn
-------
∂02-Feb-88 1907 @Score.Stanford.EDU:LES@SAIL.Stanford.EDU re: Document standard
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 88 19:07:37 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 2 Feb 88 19:01:53-PST
Date: 02 Feb 88 1906 PST
From: Les Earnest <LES@SAIL.Stanford.EDU>
Subject: re: Document standard
To: Faculty@Score.Stanford.EDU
[In reply to message sent Tue, 2 Feb 88 09:27:28 PST.]
Vaughan's proposal that the department choose a documentation language and
stick with it makes as much sense as choosing a programming language and
sticking with it. That is, it is a reasonable idea as long as you do not
take it too seriously.
It is clear that Scribe is fading away and TeX is still ascending. It
makes sense, I believe, to indoctrinate new people in the use of TeX, but
not to try to force those who are comfortable with other languages to
change their ways.
Les Earnest (closet user of PUB and TROFF)
∂02-Feb-88 1928 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: Document standard
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 88 19:28:02 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 2 Feb 88 19:21:28-PST
Date: 02 Feb 88 1926 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: Document standard
To: LES@SAIL.Stanford.EDU, Faculty@Score.Stanford.EDU, jwilson@Score.Stanford.EDU
I agree with Les that we shouldn't proscribe use of Scribe. But we
should not (1) teach it, (2) encourage it, or (3) do new dept things
in it. James Wilson should, in particular, use LaTeX and TeX if we
want to promote use of TeX.
Arthur
∂03-Feb-88 0824 @Score.Stanford.EDU:coraki!pratt@Sun.COM maintenance
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 08:24:33 PST
Received: from Sun.COM by SCORE.STANFORD.EDU with TCP; Wed 3 Feb 88 08:18:16-PST
Received: from sun.Sun.COM ([129.144.1.3]) by Sun.COM (4.0/SMI-3.2)
id AA11867; Wed, 3 Feb 88 08:23:42 PST
Received: from coraki.UUCP by sun.Sun.COM (4.0/SMI-4.0)
id AA12722; Wed, 3 Feb 88 08:23:41 PST
Received: by (4.0/SMI-4.0Beta)
id AA19753; Wed, 3 Feb 88 08:21:46 PST
Date: Wed, 3 Feb 88 08:21:46 PST
From: coraki!pratt@Sun.COM (Vaughan Pratt)
Message-Id: <8802031621.AA19753@>
To: faculty@score.stanford.edu
Subject: maintenance
In his message Les did not address my point about maintenance. The
real problem is that the department lacks the resources needed to
maintain the variety of software offerings that we would all like to
see made available. I'm all for variety if and when we can afford it.
At present we cannot. CSD-CF is grossly overworked and understaffed.
-v
∂03-Feb-88 0919 TAJNAI@Score.Stanford.EDU Re: maintenance
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 09:19:20 PST
Date: Wed 3 Feb 88 09:09:50-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Re: maintenance
To: coraki!pratt@SUN.COM, faculty@Score.Stanford.EDU
In-Reply-To: <8802031621.AA19753@>
Message-ID: <12371811411.16.TAJNAI@Score.Stanford.EDU>
Vaughan, your complaint was prompted by Nils' temporary secretary
sending you an unformatted Scribe version of the Visiting Committee's
schedule. Heidi immediately sent out a msg of apology. I'm sure
she had no idea how to run a doc file.
When Tex first came out, I used it and hated it. At that time
I used Denny Brown's macros which called upon Arthur Keller's macros --
the system was extremely unstable and frustrating. What worked one day
would not work the next.
Keith Lantz told me about Scribe and I began using it and recommended
it for administrative use. Tex is wonderful for technical material, but
it is overkill for admin. use.
When people send me material in Tex, I strip the Tex commands and replace
them with Scribe commands. The only time I have to ask for help is
for equations.
I fail to see the burden that maintaining Scribe places on CSD-CF.
It would probably take someone a month or more to convert all the
Forum documentation into Tex format.
I believe strongly that the Texers and the Scribers should be equally
supported by the department.
Carolyn
-------
∂03-Feb-88 0939 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: maintenance
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 09:39:31 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 3 Feb 88 09:30:15-PST
Date: 03 Feb 88 0934 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: maintenance
To: faculty@SCORE.Stanford.EDU
Do we have Scribe running on Unix? Are we going to get Scribe for Polya?
What will happen to Scribe users when Score goes away?
As far as Carolyn's message was concerned, had I known other people
were using my macros directly, I would have been more careful about
making changes and testing them, or having a public and private
version of them. But the current TeX/LaTeX set is much above
what was available to Carolyn in 1979. LaTeX is very much like
Scribe.
Arthur
∂03-Feb-88 1045 ullman@navajo.stanford.edu paper received
Received: from navajo.stanford.edu by SAIL.Stanford.EDU with TCP; 3 Feb 88 10:45:14 PST
Received: by navajo.stanford.edu; Wed, 3 Feb 88 10:30:31 PST
Date: Wed, 3 Feb 88 10:30:31 PST
From: Jeff Ullman <ullman@navajo.stanford.edu>
Subject: paper received
To: nail@navajo.stanford.edu, paco@navajo.stanford.edu
"Sharing the load of logic-program evaluation"
Ouri Wolfson, TR 482,Dept. of CS, Technion.
The idea is to avoid interprocessor communication by giving each processor
a complete copy of the database (or use a shared memory, I guess),
and assigning responsibility for subsets of the output tuples
to different processors.
I'm doubtful that dividing the responsibiltiy for output does much
to divide the total work, since in a recursive logic program,
you probably get very quickly into common territory, even if you
start with the set of goal tuples completely partitioned.
(Think, for example, of a genealogy, where processor 1 is to
determine the ancestors of a set of men and processor 2 the ancestors
of a set of women.)
However, the subject is interesting, and some analysis of the
idea and its potential would be excellent.
---jdu
∂03-Feb-88 1159 @Score.Stanford.EDU:LES@SAIL.Stanford.EDU re: maintenance
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 11:58:55 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 3 Feb 88 11:48:27-PST
Date: 03 Feb 88 1151 PST
From: Les Earnest <LES@SAIL.Stanford.EDU>
Subject: re: maintenance
To: faculty@SCORE.Stanford.EDU
[In reply to message sent Wed, 3 Feb 88 08:21:46 PST.]
I trust that Vaughan is prepared to apply his economic principles to
programming languages as well -- what say we ban all programming
languages other than Lisp! -Les
∂03-Feb-88 1251 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com Next MONDAY's PLANLUNCH -- Reid Simmons
Received: from WARBUCKS.AI.SRI.COM by SAIL.Stanford.EDU with TCP; 3 Feb 88 12:51:05 PST
Received: from venice by WARBUCKS.AI.SRI.COM via SMTP with TCP; Wed,
3 Feb 88 12:31:51-PST
Received: by venice (3.2/4.16) id AA20015 for planlunch@ai.sri.com;
Wed, 3 Feb 88 12:29:35 PST
Date: Wed, 3 Feb 88 12:29:35 PST
From: Amy Lansky <lansky@venice.ai.sri.com>
Message-Id: <8802032029.AA20015@venice>
To: planlunch@ai.sri.com
Subject: Next MONDAY's PLANLUNCH -- Reid Simmons
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
GENERATE, TEST AND DEBUG: A PARADIGM FOR SOLVING
INTERPRETATION AND PLANNING PROBLEMS
Reid Simmons (REID%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU)
AI Laboratory, MIT
11:00 AM, MONDAY, February 8
SRI International, Building E, Room EJ228
We describe the Generate, Test and Debug (GTD) paradigm and its use in
solving interpretation and planning problems, where the task is to
find a sequence of events that can achieve a given goal state from a
given initial state. The GTD paradigm combines associational
reasoning in the generator with causal reasoning in the debugger to
achieve a high degree of efficiency and robustness in the overall
system. The generator constructs an initial hypothesis using a
library of domain-dependent patterns that map from features in the
goal and initial states to sequences of events that could have formed
the patterns. The tester verifies the hypothesis and, if the test
fails, supplies the debugger with a causal explanation for the
failure. The debugger uses domain-independent debugging algorithms
which suggest repairs to the hypothesis by analyzing the causal
explanation and models of the domain.
This talk concentrates on how the GTD paradigm works and why its
combination of reasoning techniques enables it to achieve efficient
and robust performance. In particular, we will discuss the methods
and expressive power of our domain-independent theory of debugging
plans.
The GTD paradigm has been implemented in a program called GORDIUS. It
has been tested in several domains, including our primary domain of
geologic interpretation, the blocks world, and the Tower of Hanoi
problem. In addition, parts of the system have been used to help
diagnose manufacturing faults in semiconductor manufacture.
∂03-Feb-88 1342 hilbert@alan.stanford.edu Internships lunch
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 3 Feb 88 13:42:07 PST
Received: from alan.stanford.edu by russell.stanford.edu (3.2/4.7); Wed, 3 Feb 88 13:44:25 PST
Received: by alan.stanford.edu (3.2/4.7); Wed, 3 Feb 88 13:45:28 PST
Date: Wed 3 Feb 88 13:45:26-PST
From: Dave Hilbert <HILBERT@Alan.Stanford.EDU>
Subject: Internships lunch
To: ssp-faculty@alan.stanford.edu
Message-Id: <570923126.0.HILBERT@Alan.Stanford.EDU>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@Alan.Stanford.EDU>
The lunch regarding the CSLI internships for Symbolic Systems students
will be held in the Ventura seminar room. Sandwiches will be
available for purchase and we will provide soft drinks and cookies.
If you haven't already done so please let me know if you plan to
attend.
Dave Hilbert
(ps. A reminder. The lunch is Tuesday, February 9 at 12:00)
-------
∂03-Feb-88 1520 FACIL-mailer Polya trade-in
Received: from Tenaya.stanford.edu by SAIL.Stanford.EDU with TCP; 3 Feb 88 15:20:03 PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA00343; Wed, 3 Feb 88 15:20:02 PST
Date: Wed, 3 Feb 88 15:20:02 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8802032320.AA00343@Tenaya.stanford.edu>
To: TOM@Score.stanford.edu
Cc: facil@Sail.stanford.edu, wheaton@athena.stanford.edu
In-Reply-To: Thomas Dienstbier's message of Tue 26 Jan 88 11:39:09-PST <12369741442.13.TOM@Score.Stanford.EDU>
Subject: Polya trade-in
If Sushi could be kept in operation as a place for free student accts
without too much cost to the dept., I would be for it. -Nils
∂03-Feb-88 1619 FACIL-mailer re: Polya trade-in
To: nilsson@TENAYA.STANFORD.EDU
CC: facil@SAIL.Stanford.EDU, wheaton@ATHENA.STANFORD.EDU
From: Les Earnest <LES@SAIL.Stanford.EDU>
[In reply to message sent Wed, 3 Feb 88 15:20:02 PST.]
I believe that Sushi cannot continue operation "without too much cost to
the dept." Even if it could, its continued use would create another problem:
unsold capacity and consequently higher rates for Polya users.
Polya allegedly provides substantially more computing capacity than the
sum of Navajo and Score, but it also costs a bit more. The plan for
acquiring it was based on Navajo and Sushi going away. Even with that, it
looked like it would cause increased costs to the department for at least
the next two years.
If you now keep Sushi going, so that the students using it do not use
Polya, you are increasing the deficit and someone will have to pay. At
the time of the decision to buy Polya, I argued that such a machine should
not be purchased until the financial prospects became more advantageous,
which I estimated would be about a year. If anyone had even MENTIONED the
idea of keeping Sushi, my arguments would have been much more strident.
Les
∂03-Feb-88 1722 TAJNAI@Score.Stanford.EDU Alan Kay
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 17:22:51 PST
Date: Wed 3 Feb 88 17:17:01-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Alan Kay
To: faculty@Score.Stanford.EDU
Message-ID: <12371900100.16.TAJNAI@Score.Stanford.EDU>
As you know Alan Kay will be our Forum banquet speaker. His return
flight to LA leaves SFO at 11:55 p.m. I can have a limo pick him up
at the Faculty Club and drive him to the airport, but I wonder if
one of you would like to drive him and take the opportunity to chat
with him a bit.
Let me know asap.
Carolyn
Wed., Feb. 10, leave Faculty Club around 10:00 to 10:30.
-------
∂03-Feb-88 1723 FACIL-mailer Re: [John Sack <GQ.VVN@forsythe.stanford.edu>: The "whois" database]
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 17:23:31 PST
Date: Wed 3 Feb 88 17:18:04-PST
From: Andy Freeman <ANDY@Sushi.Stanford.EDU>
Subject: Re: [John Sack <GQ.VVN@forsythe.stanford.edu>: The "whois" database]
To: REGES@Score.Stanford.EDU, GQ.VVN@Forsythe.Stanford.EDU,
morgan@Jessica.Stanford.EDU, facil@Sail.Stanford.EDU
In-Reply-To: <12369784945.38.REGES@Score.Stanford.EDU>
Message-ID: <12371900292.9.ANDY@Sushi.Stanford.EDU>
[Sorry to take so long to reply to this.]
Stuart Reges wrote:
By the way, John Sack says that the 8-char truncation problem
mentioned at the meeting is, in fact, not a problem because, although
8-char truncation is standard, FORSYTHE looks at all chars.
No, it is a problem. There are several jafreemans. A user on a
standard bitnet host can not get to me through forsythe because the
remote site will truncate jafreeman# to jafreema. If they can send
directly to me at polya, then I'm okay (andy is short enough). Either
way, forsythe is useless.
A mail forwarding system that doesn't work for EVERYONE is a step
backwards from what we have now. We should not consider Forsythe's
current services as anything more than a bitnet address of last
resort. (That's all they advertised it as a while ago. Has that
changed?)
-andy
ps - A better name generation algorithm would stick the disambiguating
digits after the initials and would use them as necessary to
distinguish between people with the same initials whose last names
have a common prefix. Even three initials followed by a sequence of
digits would be an improvement on the current scheme.
-------
∂03-Feb-88 1756 emma@alan.stanford.edu CSLI Calendar, February 4, 3:16
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 3 Feb 88 17:56:31 PST
Received: from alan.stanford.edu by russell.stanford.edu (3.2/4.7); Wed, 3 Feb 88 17:29:46 PST
Received: by alan.stanford.edu (3.2/4.7); Wed, 3 Feb 88 17:30:51 PST
Date: Wed, 3 Feb 88 17:30:51 PST
From: emma@alan.stanford.edu (Emma Pease)
To: friends@alan.stanford.edu
Subject: CSLI Calendar, February 4, 3:16
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
4 February 1988 Stanford Vol. 3, No. 16
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 4 February 1988
12 noon TINLunch
Ventura Hall Reading: "Some Uses of Higher-Order Logic
Conference Room in Computational Linguistics"
by Dale A. Miller and Gopalan Nadathur
Discussion led by Douglas Edwards
(edwards@warbucks.ai.sri.com)
Abstract in last week's Calendar
2:15 p.m. CSLI Seminar
Room G-19 A Nonmonotonic Account of Causation
Redwood Hall Yoav Shoham
(shoham@score.stanford.edu)
Abstract in last week's Calendar
3:30 p.m. Tea
Ventura Hall
--------------
CSLI ACTIVITIES FOR NEXT THURSDAY, 11 February 1988
12 noon TINLunch
Ventura Hall Reading: "Default Reasoning, Nonmonotonic Logics,
Conference Room and the Frame Problem"
by Steve Hanks and Drew McDermott
Discussion led by Hideyuki Nakashima
(nakashim@csli.stanford.edu)
Abstract below
2:15 p.m. CSLI Seminar
Room G-19 A Type-free Theory of Types and Propositions
Redwood Hall Jon Barwise
(barwise@csli.stanford.edu)
Abstract below
3:30 p.m. Tea
Ventura Hall
--------------
NEXT WEEK'S TINLUNCH
Reading: "Default Reasoning, Nonmonotonic Logics,
and the Frame Problem"
by Steve Hanks and Drew McDermott
Proc. of AAAI-86, pp. 328-33
Discussion led by Hideyuki Nakashima
(nakashim@csli.stanford.edu)
11 February 1988
In the beginning was the frame problem. Then came nonmonotonic
logics. Nonmonotonic logics are meant to be the logical counterpart
of the human default-reasoning process, which is capable of jumping to
conclusions, neglecting irrelevant conditions without even thinking
about them. The history is explained clearly in the article, which is
a good introduction to the field.
However, the authors claim that nonmonotonic logics are not the
solution to the frame problem. They are too weak to capture human
default reasoning. The temporal projection problem (now known as "the
Yale shooting problem") is introduced as an example.
I want to discuss (0) the view that the frame problem is
unsolvable, (1) why humans do not seem to have the same problem, (2)
whether we need nonmonotonic logics to capture default reasoning.
--------------
NEXT WEEK'S SEMINAR
A Type-free Theory of Types and Propositions
Jon Barwise
(barwise@csli.stanford.edu)
11 February 1988
Since the beginning of the century, starting with Frege and Russell,
theories of types and propositions have played an important role in
logic and the foundations of mathematics. Recent applications in
computer science and in the analysis of natural language have brought
them back into the limelight. In this talk I will outline a theory of
types and propositions that not only avoids the paradoxes that plagued
Frege and Russell, but also "explains" them. Familiarity with
situation theory is needed only for the last ten minutes of the talk.
∂04-Feb-88 0815 HEMENWAY@Score.Stanford.EDU Meeting Reminder
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Feb 88 08:15:07 PST
Date: Thu 4 Feb 88 08:01:08-PST
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: Meeting Reminder
To: phd-adm@Score.Stanford.EDU
Message-ID: <12372061049.15.HEMENWAY@Score.Stanford.EDU>
This is just to remind everyone of our lunch meeting today at 12 in
MJH 252. Procedures for the admission process and a number of PhD
program proposals/issues are on the agenda.
--Sharon
-------
∂04-Feb-88 0836 LOGMTC-mailer various talks
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 4 Feb 88 08:35:55 PST
Received: from alan.stanford.edu by russell.stanford.edu (3.2/4.7); Thu, 4 Feb 88 08:38:59 PST
Received: from localhost by alan.stanford.edu (3.2/4.7); Thu, 4 Feb 88 08:40:04 PST
To: Logic@alan
Subject: various talks
Date: Thu, 04 Feb 88 08:40:03 PST
From: Jon Barwise <barwise@alan.stanford.edu>
There are various logic related events listed in this week's csli calendar,
including my talk next week.
------- Forwarded Message
Return-Path: emma@alan.stanford.edu
Received: from russell.stanford.edu by alan.stanford.edu (3.2/4.7); Wed, 3 Feb 88 17:53:44 PST
Received: from alan.stanford.edu by russell.stanford.edu (3.2/4.7); Wed, 3 Feb 88 17:29:46 PST
Received: by alan.stanford.edu (3.2/4.7); Wed, 3 Feb 88 17:30:51 PST
Date: Wed, 3 Feb 88 17:30:51 PST
From: emma@alan.stanford.edu (Emma Pease)
To: friends@alan.stanford.edu
Subject: CSLI Calendar, February 4, 3:16
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
4 February 1988 Stanford Vol. 3, No. 16
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 4 February 1988
12 noon TINLunch
Ventura Hall Reading: "Some Uses of Higher-Order Logic
Conference Room in Computational Linguistics"
by Dale A. Miller and Gopalan Nadathur
Discussion led by Douglas Edwards
(edwards@warbucks.ai.sri.com)
Abstract in last week's Calendar
2:15 p.m. CSLI Seminar
Room G-19 A Nonmonotonic Account of Causation
Redwood Hall Yoav Shoham
(shoham@score.stanford.edu)
Abstract in last week's Calendar
3:30 p.m. Tea
Ventura Hall
--------------
CSLI ACTIVITIES FOR NEXT THURSDAY, 11 February 1988
12 noon TINLunch
Ventura Hall Reading: "Default Reasoning, Nonmonotonic Logics,
Conference Room and the Frame Problem"
by Steve Hanks and Drew McDermott
Discussion led by Hideyuki Nakashima
(nakashim@csli.stanford.edu)
Abstract below
2:15 p.m. CSLI Seminar
Room G-19 A Type-free Theory of Types and Propositions
Redwood Hall Jon Barwise
(barwise@csli.stanford.edu)
Abstract below
3:30 p.m. Tea
Ventura Hall
--------------
NEXT WEEK'S TINLUNCH
Reading: "Default Reasoning, Nonmonotonic Logics,
and the Frame Problem"
by Steve Hanks and Drew McDermott
Proc. of AAAI-86, pp. 328-33
Discussion led by Hideyuki Nakashima
(nakashim@csli.stanford.edu)
11 February 1988
In the beginning was the frame problem. Then came nonmonotonic
logics. Nonmonotonic logics are meant to be the logical counterpart
of the human default-reasoning process, which is capable of jumping to
conclusions, neglecting irrelevant conditions without even thinking
about them. The history is explained clearly in the article, which is
a good introduction to the field.
However, the authors claim that nonmonotonic logics are not the
solution to the frame problem. They are too weak to capture human
default reasoning. The temporal projection problem (now known as "the
Yale shooting problem") is introduced as an example.
I want to discuss (0) the view that the frame problem is
unsolvable, (1) why humans do not seem to have the same problem, (2)
whether we need nonmonotonic logics to capture default reasoning.
--------------
NEXT WEEK'S SEMINAR
A Type-free Theory of Types and Propositions
Jon Barwise
(barwise@csli.stanford.edu)
11 February 1988
Since the beginning of the century, starting with Frege and Russell,
theories of types and propositions have played an important role in
logic and the foundations of mathematics. Recent applications in
computer science and in the analysis of natural language have brought
them back into the limelight. In this talk I will outline a theory of
types and propositions that not only avoids the paradoxes that plagued
Frege and Russell, but also "explains" them. Familiarity with
situation theory is needed only for the last ten minutes of the talk.
------- End of Forwarded Message
∂04-Feb-88 0925 LOGMTC-mailer Logic Seminar
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 4 Feb 88 09:24:12 PST
Received: by russell.stanford.edu (3.2/4.7); Thu, 4 Feb 88 09:27:19 PST
Date: Thu 4 Feb 88 09:27:17-PST
From: Sol Feferman <SF@Russell.Stanford.EDU>
Subject: Logic Seminar
To: logic@Russell.Stanford.EDU
Cc: cork@RICE.EDU, longo@THEORY.CS.CMU.EDU
Message-Id: <570994037.0.SF@Russell.Stanford.EDU>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@Russell.Stanford.EDU>
Speaker: S. Feferman
Title: The polymorphic typed lambda calculus (and all that) in a type-free
framework.
Time: Tuesday, Feb.9, 4:15-5:30
Place: Room 381-T, Math Corner, Stanford
Abstract:
In this talk I shall describe a simple axiomatic type-free theory IOC
of operations and classes (=types) which is equivalent to a fragment of
an impredicative theory for constructive mathematics that I introduced
in 1975. It will be shown how the polymorphic typed lambda calculus PT
as well as calculi for subtyping can be developed in a straightforward
way within IOC. The theory also has advantages not enjoyed by PT, including
the availability of: (i) a much wider class of type constructions,
(ii)partial function types, (iii) general fixed point operators, (iv) a
setting for proofs of program termination, and (v) direct recursion-
theoretic models. On the other hand it will be shown how an elementary
(i.e., predicative) subtheory EOC of IOC can serve the same essential
purposes, from which I conclude that the claimed necessity of impredicative
comprehension principles is a red herring so far as applications to
computer science are concerned.
-------
∂04-Feb-88 0949 FACIL-mailer Polya/Sushi
Received: from polya (polya.Stanford.EDU) by SAIL.Stanford.EDU with TCP; 4 Feb 88 09:49:40 PST
Received: by polya (1.2/inc-1.2)
id AA20812; Thu, 4 Feb 88 09:49:34 pst
Date: Thu, 4 Feb 88 09:49:34 pst
From: tom@polya.stanford.edu (Tom Dienstbier)
Message-Id: <8802041749.AA20812@polya>
To: Nilsson@tenaya.stanford.edu
Cc: facil@sail.stanford.edu, wheaton@athena.stanford.edu
Subject: Polya/Sushi
I think that one of the things that we are failing to do here is to provide
the computer resources that the students want/maybe deserve. If we did not
have to worry about funding, what would we provide for student computing? It
seems that we have a mix of students that want Unix and are still happy with
20's. My idea is to be able to provide both by subsidizing the cost of these
machines with 602 funds. A practice that was used in the early CF days to
offset the start-up costs and keep the rates down.
Eventually Polya will start paying for itself along with the 20's fade out.
By running Sushi I feel that this would not prolong this fade out trend.
tom
∂04-Feb-88 1133 FACIL-mailer Re: Polya/Sushi
Received: from Pescadero (Pescadero.Stanford.EDU) by SAIL.Stanford.EDU with TCP; 4 Feb 88 11:33:02 PST
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA02704; Thu, 4 Feb 88 11:32:56 PST
Date: Thu, 4 Feb 88 11:32:56 PST
From: "David Cheriton" <cheriton@pescadero.stanford.edu>
Message-Id: <8802041932.AA02704@Pescadero>
To: Nilsson@tenaya.stanford.edu, tom@polya.stanford.edu
Subject: Re: Polya/Sushi
Cc: facil@sail.stanford.edu, wheaton@athena.stanford.edu
I'm puzzled by this whole discussion. It was my understanding at the time
we decided to go for Polya that we were being killed by maintenance costs.
I also recall the budget analysis of the time indicating that the transition
should cost in the range of $20K given the first 2 year savings on maintenance
for the 8700. I also understood, or perhaps presumed, that the department
would buy a portion of Polya comparable to sushi and that we would shut down
sushi. Moreover, part of the thinking was to get our students based in Unix,
rather than an obselete, discontinued operating system like TOPS-20.
I dont see how we can avoid dramatic financial damage unless we stick to
this plan or improve on it some how. The sooner this dept. gets rid of
every last Dec 20 system, the better off we are!
∂04-Feb-88 1136 STAGER@Score.Stanford.EDU Final Exams
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Feb 88 11:36:09 PST
Date: Thu 4 Feb 88 11:29:26-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: Final Exams
To: instructors@Score.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12372098970.35.STAGER@Score.Stanford.EDU>
Time to begin preparing for Winter Quarter final exams. Please respond to
the following by Friday, February 12:
1)Have you changed classrooms since the beginning of the quarter (and not
let me know)?
2)Are you giving a take-home exam instead of an in-class final?
3)Will you need a larger room, or an extra room in addition to your own, in
order to provide alternate seating during the exam? If so, how many total
seats will you need?
4)Will you be giving an early exam, in addition to your regularly scheduled
exam? If so, please let me know the day, time, and room size you plan on.
The final examination schedule is printed on page 6 of the Winter Quarter
Stanford University Time Schedule. If your class begins at an odd time
(e.g. 2:30 or 2:45), your exam will be held in "the same time slot(s) as
classes starting at the regular time with the same hour designation" (under
the 2:15 slot for this example).
Contact me if you have any questions.
Thanks again for your cooperation.
Claire
-------
∂04-Feb-88 1526 TAJNAI@Score.Stanford.EDU Reminder to RSVP
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Feb 88 15:26:37 PST
Date: Thu 4 Feb 88 15:18:15-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Reminder to RSVP
To: faculty@Score.Stanford.EDU
Message-ID: <12372140625.31.TAJNAI@Score.Stanford.EDU>
If you have not sent in your RSVP for Forum meal functions next
week, please do so. We must guarantee the numbers.
Carolyn
-------
∂04-Feb-88 1630 AAAI-OFFICE@SUMEX-AIM.Stanford.EDU Election Results
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Feb 88 16:30:16 PST
Date: Thu, 4 Feb 88 16:27:18 PST
From: AAAI <AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>
Subject: Election Results
To: officers: ;
cc: aaaI-OFFICE@SUMEX-AIM.Stanford.EDU, hes@scrc-vallecito.arpa
Telephone: (415) 328-3123
Postal-Address: 445 Burgess Drive, Menlo Park, CA 94025
Message-ID: <12372153195.64.AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>
I'm pleased to announce that the voting for the new committees and chairs
was an almost unanimous (only one descending vote).
We would like to thank the past chairs for all their work over the
years (however, they will be still serving in a steering capacity
for the next 2 years!). They helped form the tenor and direction of
the AAAI's programs and services and without their energy and creativity,
those formative programs could have faltered.
We would also like to welcome the newly elected standing chairs -
Hector Levesque, Symposium Series; Howard Shrobe, Conference;
Bruce Buchanan, Finance; Peter Hart, Workshops; and Raj Reddy as
the acting chair to the Scholarship Committee. We hope you can
congradulate them at the next Council meeting which will be held
either Friday, March 25 or Thursday afternoon, March 24 (the exact
date is still pending).
---Claudia
-------
∂05-Feb-88 1001 HEMENWAY@Score.Stanford.EDU Batch 1 Ready after 4:00
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 88 10:01:26 PST
Date: Fri 5 Feb 88 09:54:33-PST
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: Batch 1 Ready after 4:00
To: phd-adm@Score.Stanford.EDU
Message-ID: <12372343840.21.HEMENWAY@Score.Stanford.EDU>
The first set of application folders will be available to all committee
members after 4:00 this afternoon. It would be easiest for me if you
could stop by and pick them up but please let me know if you would prefer
me to put them in your mailbox or office. All applications (and rating
sheets, of course) MUST be returned to me by 10:00 am on Monday
morning (so that we can reshuffle the folders and have the second
batch ready for distribution that afternoon). Here is the schedule
that we will be following:
Available (after 4:00) Due (by 10:00)
______________________ _________________
Batch 1 Friday, Feb. 5 Monday, Feb. 8
Batch 2 Monday, Feb. 8 Thursday, Feb. 11
Batch 3 Thursday, Feb. 11 Tuesday, Feb. 16
Batch 4 Tuesday, Feb. 16 Friday, Feb. 19
It is essential that everyone adheres to this schedule since we
shuffle all of the folders between batches.
We are aiming for the Round 1 meeting on either Feb. 22 or Feb. 23 (to
be announced definitely shortly).
I have also made copies of six applications (of people we accepted)
from last year which you can pick up anytime today. I hope that you
will find these useful.
--Sharon
-------
∂05-Feb-88 1017 LOGMTC-mailer Logic lunch
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 5 Feb 88 10:17:24 PST
Received: from alan.stanford.edu by russell.stanford.edu (3.2/4.7); Fri, 5 Feb 88 10:20:34 PST
Received: from localhost by alan.stanford.edu (3.2/4.7); Fri, 5 Feb 88 10:21:31 PST
To: logic@alan.stanford.edu
Subject: Logic lunch
Date: Fri, 05 Feb 88 10:21:28 PST
From: Jon Barwise <barwise@alan.stanford.edu>
Don't forget logic lunch as usual next Monday. Faculty lounge, 3rd floor,
math building, at noon.
∂05-Feb-88 1033 @Score.Stanford.EDU:ag@pepper.stanford.edu Re: Batch 1 Ready after 4:00
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 88 10:32:17 PST
Received: from pepper.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 5 Feb 88 10:23:47-PST
Received: by pepper.stanford.edu; Fri, 5 Feb 88 10:26:10 PST
Date: 5 Feb 1988 1026-PST (Friday)
From: Anoop Gupta <ag@pepper.stanford.edu>
To: Sharon Hemenway <HEMENWAY@score.stanford.edu>
Cc: phd-adm@score.stanford.edu
Subject: Re: Batch 1 Ready after 4:00
In-Reply-To: Sharon Hemenway <HEMENWAY@score.stanford.edu> /
Fri 5 Feb 88 09:54:33-PST.
<12372343840.21.HEMENWAY@Score.Stanford.EDU>
Sharon: I would like to have copies of applications of not only those
students who we accepted, but also of those we rejected. In fact, I would
like to have copies of two example applications of students we accepted,
two that were in the second round but were rejected, and two that did not
make it to the second round. Thanks. --- Anoop.
∂05-Feb-88 1035 HEMENWAY@Score.Stanford.EDU Re: Batch 1 Ready after 4:00
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 88 10:35:51 PST
Date: Fri 5 Feb 88 10:28:42-PST
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: Re: Batch 1 Ready after 4:00
To: ag@pepper.Stanford.EDU
cc: phd-adm@Score.Stanford.EDU
In-Reply-To: Message from "Anoop Gupta <ag@pepper.stanford.edu>" of Fri 5 Feb 88 10:26:00-PST
Message-ID: <12372350058.21.HEMENWAY@Score.Stanford.EDU>
Anoop:
I will do what I can but, quite honestly, as all of last year's
applications are buried up on the fifth floor (in purely alphabetical
order), I just don't know if I will be able to do it today. I'll get
you the copies as soon as I can...
--Sharon
-------
∂05-Feb-88 1038 GENESERETH@Score.Stanford.EDU Re: Batch 1 Ready after 4:00
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 88 10:38:28 PST
Date: Fri 5 Feb 88 10:29:05-PST
From: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Subject: Re: Batch 1 Ready after 4:00
To: ag@pepper.Stanford.EDU
cc: HEMENWAY@Score.Stanford.EDU, phd-adm@Score.Stanford.EDU
In-Reply-To: Message from "Anoop Gupta <ag@pepper.stanford.edu>" of Fri 5 Feb 88 10:26:00-PST
Message-ID: <12372350126.41.GENESERETH@Score.Stanford.EDU>
Sharon,
I like Anoop's suggestion. I realize that you havew already xeroxed
several folders for wveryone. If it osn't too much trouble, it would
be good to xerox the additional folders as Anoop suggests. It is
unfortunate that we didn't think of this earlier, but progress
in the way we do things isn't always scheduled at the most
convenient times.
mrg
-------
∂05-Feb-88 1518 HADDAD@Sushi.Stanford.EDU BATS Friday, Feb 19 at Xerox
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 88 15:18:27 PST
Date: Fri 5 Feb 88 14:59:04-PST
From: Ramsey Haddad <HADDAD@Sushi.Stanford.EDU>
Subject: BATS Friday, Feb 19 at Xerox
To: aflb.all@Sushi.Stanford.EDU, su-events@Sushi.Stanford.EDU
Message-ID: <12372399274.37.HADDAD@Sushi.Stanford.EDU>
The next Bay Area Theory Seminar will be held at XEROX PARC on Friday,
February 19, from 10 am to 3 pm. Any Stanford people who plan to
attend should send me a note (so that we can give Xerox an approximate
mouth & stomach count.)
Driving Directions: Xerox PARC is at 3333 Coyote Hill Rd., Palo Alto.
The best way to get here from almost anywhere distant is to take
I-280, get off at Page Mill Rd., go east 1/2 mile, turn right on
Coyote Hill Rd, pass grazing horses, and finally turn left into PARC,
just over the crest of the hill. Park in the visitor's parking, or
any legal spot (including the Xerox building across the street) if
that lot is full. Enter at the auditorium entrance, down some stairs
which are to the left when one faces the building from the visitors's
parking lot.
-----------------------------------------------------------------------
LOWER BOUNDS ON THE STRENGTH OF CRYPTOGRAPHIC ASSUMPTIONS
Steven Rudich, UC-Berkeley
A SECRET KEY EXCHANGE PROTOCOL is a protocol whereby Alice and Bob
agree (with high probability) on a secret, but where an eavesdropper,
Eve, overhearing their entire conversation, cannot compute this secret
with any polynomial probability. Such protocols are known to exist
given the existence of one-way functions with special properties, such
as trapdoor or Diffie-Hellman functions. We give strong evidence that
such a protocol cannot be proved secure based solely on the assumption
that a pseudo-random one-way function exists.
There are two approaches one might take to provide such evidence.
An information-theoretic approach would model a pseudo-random function
by a black-box for a purely random function; all parties involved
would have access to this black-box. Alice, Bob and Eve need no
longer be polynomial-time machines, but each would have a polynomial
limit on the number of times they are allowed to access the black-box.
The known schemes for secret key exchange (using trapdoor or
Diffie-Hellman functions) are all secure in an information-type model;
furthermore, these schemes were all shown to be secure in the standard
model (polynomial-time Turing Machines) by an appeal to their security
in the information-theoretic model. A second approach would be to
construct an oracle relative to which a pseudo-random one-way function
existed, but no protocol was secure. This would show that the
assumption that a one-way function exists is not sufficient to prove
the correctness of a protocol using techniques which relativize.
Our approach combines both of the above. We first show that no
protocol can be information-theoretically secure, giving a general
strategy for Eve to break the scheme. We then show that, if P=NP, and
if Alice and Bob are polynomial-time machines, Eve's strategy can
actually be implemented in polynomial-time. THUS, FOR ANY SECRET KEY
EXCHANGE PROTOCOL WHICH USES A ONE-WAY FUNCTION AS A BLACK BOX,
PROVING THE PROTOCOL IS SECURE IS AS HARD AS PROVING P<>NP. As a
corollary, we get an oracle as in the second approach above: take any
oracle relative to which P=NP, and add another oracle at random.
We feel that this approach, suggested by Manuel Blum, of first
taking a world where no cryptography is possible (P=NP) and then
allowing all parties access to a random function, is the correct way
of modelling the implications of a pseudo-random one-way function. By
allowing all parties access to a random function of a special form, we
can similarly isolate the implications of other cryptographic
assumptions. For example, we can alter our proof slightly and show
that key exchange is also impossible using a random public key
encryption scheme, unless P<>NP.
(Joint work with Russell Impagliazzo)
--------------------------------------------------------------------------
A TRADEOFF BETWEEN SPACE AND EFFICIENCY FOR ROUTING TABLES
David Peleg, Stanford
In designing a routing scheme for a communication network it is
desirable to use as short as possible paths for routing messages,
while keeping the routing information stored in the processors' local
memory as succinct as possible. The efficiency of a routing scheme is
measured in terms of its STRETCH FACTOR - the maximum ratio between
the length of a route computed by the scheme and that of a shortest
path connecting the same pair of vertices.
Previous work has concentrated on finding good routing schemes for
special classes of network topologies. The talk deals with the problem
for general networks. Our results exhibit a tradeoff between the
efficiency of a routing scheme and its space requirements, and supply
almost tight upper and lower bounds for this tradeoff. Specifically,
any routing scheme for general n-vertex networks that achieves a
stretch factor k>0 must use a total of
1+1/(2k+4)
Omega(n )
bits of routing information in the networks, while on the other hand
we construct a family of hierarchical routing schemes (for every fixed
k>0), which guarantee a stretch factor of O(k) and require storing a
total of
1+1/k
O(n )
bits of routing information in the network.
(Joint work with Eli Upfal from IBM Almaden.)
-----------------------------------------------------------------------
CONSTRUCTION AND APPLICATION OF EUCLIDEAN MAXIMUM
SPANNING TREES
Frances Yao, Xerox PARC
The construction of minimum spanning trees (MST) and that of maximum
spanning trees (MXST) are algorithmically equivalent in the context of
graphs, but they are distinct in a geometric setting when edge weights
correspond to interpoint distances. Previously, efficient algorithms
were available only in the case of computing Euclidean MST. We will
give an O(n log n) algorithm for finding a Euclidean MXST on n points,
and demonstrate that a MXST is a useful object. As an application,
consider the following problem: Given a set of n points in the plane,
partition the set into k subsets of minimum diameter, i.e., the
largest of the k diameters should be as small as possible. This
problem is NP-complete even for k=3; but for k=2, an O(n log n)
algorithm can be obtained through the observation that an optimal
partition is determined by a MXST of the points.
(Joint work with Tetsuo Asano, Michael Paterson, and others.)
-------------------------------------------------------------------
COVERING ORTHOGONAL POLYGONS WITH STAR POLYGONS
Arvind Raghunathan, UC-Berkeley
We consider the problem of covering simple orthogonal polygons with
star polygons. A star polygon contains a point p, such that for every
point q in the star polygon, there is an orthogonally convex polygon
containing p and q.
In general, orthogonal polygons can have concavities (dents) with four
possible orientations. In this case, we show that the polygon
covering problem can be reduced to the problem of covering a weakly
triangulated graph with a minimum number of cliques. We thus obtain
an O(n↑5) algorithm. Since weakly triangulated graphs are perfect, we
also obtain the following duality relationship: the minimum numberof
star polygons needed to cover an orthogonal polygon P without holes is
equal to the maximum number of points of P, no two of which can be
contained together in a covering star polygon.
In the case where the polygon has at most three dent orientations, we
show that the polygon covering problem can be reduced to the problem
of covering a triangulated (chordal) graph with a minimum number of
cliques. This gives us an O(n↑3) algorithm.
(Joint work with Rajeev Motwani and Huzur Saran)
-------
∂07-Feb-88 1926 @WARBUCKS.AI.SRI.COM,@venice:lansky@venice.ai.sri.com REMINDER -- Monday Planlunch -- Reid Simmons
Received: from WARBUCKS.AI.SRI.COM by SAIL.Stanford.EDU with TCP; 7 Feb 88 19:26:44 PST
Received: from venice by WARBUCKS.AI.SRI.COM via SMTP with TCP; Sun,
7 Feb 88 19:18:13-PST
Received: by venice (3.2/4.16) id AA23733 for
planlunch_reminder@WARBUCKS.ai.sri.com; Sun, 7 Feb 88 19:17:27 PST
Date: Sun 7 Feb 88 19:17:26-PST
From: Amy Lansky <LANSKY@venice.ai.sri.com>
Subject: REMINDER -- Monday Planlunch -- Reid Simmons
To: planlunch_reminder@WARBUCKS.ai.sri.com
Message-Id: <571288646.0.LANSKY@VENICE.ARPA>
Mail-System-Version: <SUN-MM(213)+TOPSLIB(128)@VENICE.ARPA>
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
GENERATE, TEST AND DEBUG: A PARADIGM FOR SOLVING
INTERPRETATION AND PLANNING PROBLEMS
Reid Simmons (REID%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU)
AI Laboratory, MIT
11:00 AM, MONDAY, February 8
SRI International, Building E, Room EJ228
We describe the Generate, Test and Debug (GTD) paradigm and its use in
solving interpretation and planning problems, where the task is to
find a sequence of events that can achieve a given goal state from a
given initial state. The GTD paradigm combines associational
reasoning in the generator with causal reasoning in the debugger to
achieve a high degree of efficiency and robustness in the overall
system. The generator constructs an initial hypothesis using a
library of domain-dependent patterns that map from features in the
goal and initial states to sequences of events that could have formed
the patterns. The tester verifies the hypothesis and, if the test
fails, supplies the debugger with a causal explanation for the
failure. The debugger uses domain-independent debugging algorithms
which suggest repairs to the hypothesis by analyzing the causal
explanation and models of the domain.
This talk concentrates on how the GTD paradigm works and why its
combination of reasoning techniques enables it to achieve efficient
and robust performance. In particular, we will discuss the methods
and expressive power of our domain-independent theory of debugging
plans.
The GTD paradigm has been implemented in a program called GORDIUS. It
has been tested in several domains, including our primary domain of
geologic interpretation, the blocks world, and the Tower of Hanoi
problem. In addition, parts of the system have been used to help
diagnose manufacturing faults in semiconductor manufacture.
-------
∂08-Feb-88 0825 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu robots for lunch!
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 88 08:25:40 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 8 Feb 88 07:51:21-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA03648; Mon, 8 Feb 88 07:53:42 PST
Date: Mon, 8 Feb 88 07:53:42 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8802081553.AA03648@Tenaya.stanford.edu>
To: faculty@score
Cc: gibbons@sierra, kino@sierra, johnston@sierra, fullerton@sierra
Subject: robots for lunch!
Our faculty lunch this Tuesday, Feb 9 12:15 in mjh146 will
focus on the subject of "roboticizing" one of the new
computer science buildings. Jean-Claude Latombe, Yoav Shoham,
and Michael Genesereth and their students have been giving
serious thought to the possibility of having several mobile
robots roaming around our new building and will talk about
their plans at lunch. They will be looking forward to your
ideas about this.
(George Wheaton: could you let Voijka and any others who might
be interested in this topic know about it?)
-Nils
∂08-Feb-88 0837 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Forsythe Lectures
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 88 08:37:18 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 8 Feb 88 08:12:43-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA03672; Mon, 8 Feb 88 08:17:41 PST
Date: Mon, 8 Feb 88 08:17:41 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8802081617.AA03672@Tenaya.stanford.edu>
To: csd-list@score
Subject: Forsythe Lectures
Don't forget the Forsythe Lectures this evening (Monday, Feb. 8)
and tomorrow. Ted Shortliffe is the Forsythe Lecturer this
year. This evening's public lecture "Intelligent Systems for
Biomedicine" will be at 7:30 pm in Fairchild Auditorium
(reception follows in the Foyer of Fairchild). Tomorrow
(Feb 9) Ted will speak on "Uncertainty About Uncertain
Reasoning" at 4:15 in Bishop Auditorium in the GSB.
-Nils
∂08-Feb-88 1216 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Visiting Committee Report
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 88 12:16:41 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 8 Feb 88 12:10:34-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA03864; Mon, 8 Feb 88 12:15:30 PST
Date: Mon, 8 Feb 88 12:15:30 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8802082015.AA03864@Tenaya.stanford.edu>
To: faculty@score
Subject: Visiting Committee Report
Dear Faculty and Senior Staff:
Thanks to all of you for your excellent efforts last week with the
Computer Science Dept. Visiting Committee. They will be writing us
(and the Dean and the Provost) a formal report, but in the meantime I
will try to summarize what they had to say about us. The following is
from my notes taken during their oral report to the Provost and the
Dean.
The Committee spent two long days at Stanford, and I think had
adequate time to learn about our educational and research programs and
about special concerns of students and faculty.
The major conclusion: We are a strong department, BUT we have some
problems. The Committee made some recommendations about how we ought
to go about solving these problems. I agree with these
recommendations wholeheartedly, and I have re-arranged my priorities
to work very hard on them. (I have reason to think the Provost and
the Deans will be supportive.) The Visiting Committee would like to
return in about 18 months to check on our progress.
The major findings and recommendations:
1) The undergraduate program seems off to a good start. One would
hope that faculty involvement in the program will accelerate. It is
to be expected that the curriculum will evolve as more faculty
participate. The University should provide more TA support.
2) "Systems research" at Stanford is undergoing a positive transition.
All signs are positive! The CSL faculty, under the leadership of John
Hennessy, received hearty congratulations!
3) We have a problem in the "Foundations" area (no surprise).
Leadership is absent. There is a lack of research funding. People
have left. "Theory" is vitally important to the Department, and we
must not allow it to slip! We should take immediate steps to attract
a world-renowned person (maybe two) in this area and to replace
losses.
4) "Robotics" research is undergoing a positive transition and is
building on strength. Excellent cooperation with other departments.
Excellent research programs spanning the major areas of robotics and
linking to the rest of AI. Latombe is playing an important leadership
role. "We really are positively impressed with robotics at Stanford;
it's a lot stronger than we thought it was." An additional faculty
member in this area is recommended.
5) KSL is justly famous for its work on knowledge-based systems, and
steps must be taken to ensure it continues strong. Some of the
funding in this area appears to be at risk (DARPA). [I will be
working with Ed Feigenbaum to implement some of the committee's
specific recommendations.]
6) In general, AI at Stanford is overly "polarized," and this
is discouraging to students. Leadership (in the sense of a central
focus helping to provide cohesion) seems to be lacking. The situation
at Stanford probably reflects the situation in the field generally
in AI.
7) The Department has been involved in a number of "bridge-building"
activities (with Aero/Astro, C.E., M.E., E.E., Medicine, etc.), and
these have generally worked well, but it should now pay more attention
to its own "core problems." Perhaps a moratorium on bridge-building is
in order.
8) The Department should hire a woman faculty member. There are
several excellent women computer scientists, and there is no good
reason why the Department does not already have a woman faculty
member.
9) The Department should do more to encourage contacts among
colleagues. It has probably overdone the "individualism" thing.
Rampant individualism is especially hard on junior faculty. The
senior faculty should pay more attention to establishing mentoring
relationships with junior faculty.
10) The M.S. programs get "high marks."
11) The Ph.D. program: supporting the first-year students is a good
idea---especially appreciated by the students. The Committee felt
that future students in AI and in "foundations" will not find adequate
funding and/or faculty attention, and some students feel that they
could not honestly recommend that students interested these areas come
to Stanford.
The above is an "unofficial summary" and will undoubtedly be elaborated
in the letter to come. Nevertheless, I concur with the findings and
recommendations and hope to be reporting progress as we make it. I'll
need the help of all of you. As specific plans develop I'll solicit
your comments and support.
In the meantime, if there are other points that you think ought to have
been made by the Committee or advice to me about how to proceed with
our agenda for the next 18 months, please do let me know.
I have a pretty positive feeling now that I have "marching orders," and
I have my usual pathological optimism that we can fix our problems.
-Nils
∂08-Feb-88 1603 hilbert@alan.stanford.edu Reminder about Internships lunch
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 8 Feb 88 16:03:13 PST
Received: from alan.stanford.edu by russell.stanford.edu (3.2/4.7); Mon, 8 Feb 88 16:05:17 PST
Received: by alan.stanford.edu (3.2/4.7); Mon, 8 Feb 88 16:06:25 PST
Date: Mon 8 Feb 88 16:06:23-PST
From: Dave Hilbert <HILBERT@Alan.Stanford.EDU>
Subject: Reminder about Internships lunch
To: ssp-faculty@alan.stanford.edu
Message-Id: <571363583.0.HILBERT@Alan.Stanford.EDU>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@Alan.Stanford.EDU>
This to remind you that the lunch for students and faculty interested
in the CSLI internship program is tommorrow (Tuesday) at 12:00 in the
Ventura seminar room.
We plan to ask the faculty who attend to give a brief description of
their research interests and especially of projects they may have in
mind for student interns to work on.
See you tommorrow.
Dave Hilbert
-------
∂08-Feb-88 1622 hilbert@alan.stanford.edu Cog. Sci. grad programs at other institutions
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 8 Feb 88 16:22:35 PST
Received: from alan.stanford.edu by russell.stanford.edu (3.2/4.7); Mon, 8 Feb 88 16:25:01 PST
Received: by alan.stanford.edu (3.2/4.7); Mon, 8 Feb 88 16:26:08 PST
Date: Mon 8 Feb 88 16:26:06-PST
From: Dave Hilbert <HILBERT@Alan.Stanford.EDU>
Subject: Cog. Sci. grad programs at other institutions
To: ssp-faculty@alan.stanford.edu
Message-Id: <571364766.0.HILBERT@Alan.Stanford.EDU>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@Alan.Stanford.EDU>
We are interested in gathering information about graduate study in
cognitive science at other institutions to help us in advising our
students about post-graduation options. What follows is a list of
schools that have graduate programs in cognitive science. Any
information that you can give me about who to contact at these places
to get information about their program would be very helpful. Any
additions to the list would also be appreciated.
Brown
Brandeis
UCSD
USC
MIT
CMU
Rochester
Rutgers
Edinburgh
SUNY at Binghamton
Thanks.
Dave Hilbert
-------
∂08-Feb-88 1656 TAJNAI@Score.Stanford.EDU Nils Nilsson's announcement
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 88 16:56:29 PST
Date: Mon 8 Feb 88 16:50:08-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Nils Nilsson's announcement
To: faculty@Score.Stanford.EDU
cc: debra@Krakatoa.Stanford.EDU
Message-ID: <12373205926.40.TAJNAI@Score.Stanford.EDU>
MEMO TO: Prof. D. Knuth - > Prof. N. Nilsson
FROM: Dan DeBra, Membership Chairman
SUBJECT: Sigma Xi Annual Membership Nominations Luncheon
DATE: January 25, 1988
It is time again to nominate students, faculty or others who are
qualified for Associate or Full Membership in Sigma Xi, the world wide
scientific research society.
Each year we identify who will coordinate the effort in the department(s)
most likely to have candidates. We have a lunch and then a briefing for the
admin. assist. or secretary who will help in the logistics of preparing
and forwarding the nominating forms (which will be supplied). If you are
not able to serve as our rep of Sigma Xi, please help us identify who
in your dept. is and pass this memo to them.
The lunch will be held in the Aero & Astro conference room, 026 (end of
the hall towards Terman) on Thursday, 1988 Feb. 11 at 12 noon. After the
special (Chinese) lunch, we will brief the attendees on the following:
1. Forms (supplies will be distributed)
2. Schedule for nomination, election, and initiation banquet
We hope you and your assistant will join us, please RSVP:
3-5303 (Ida) or 3-3388 (Susan or DeBra)
email: DeBra@krakatoa
NB: Since this meeting conflicts with the Computer Forum, you probably
will not be able to attend. However, you may wish to participate.
If you are interested, send msg to Prof. DeBra. Also, let
me know that it is being done. Thanks, Carolyn Tajnai
-------
∂09-Feb-88 0926 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Would someone send me this paper?
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Feb 88 09:26:53 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 9 Feb 88 09:20:50-PST
Received: by lindy.stanford.edu; Tue, 9 Feb 88 09:25:50 PST
Received: by Forsythe.Stanford.EDU; Tue, 9 Feb 88 09:23:11 PST
Received: by BYUADMIN (Mailer X1.25) id 5108; Tue, 09 Feb 88 10:19:42 MST
Date: Tue, 9 Feb 88 10:16:29 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Paul F. Dietz" <DIETZ%sdr.slb.com@relay.cs.net>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Paul F. Dietz" <DIETZ%sdr.slb.com@relay.cs.net>
Subject: Would someone send me this paper?
To: Local Distribution <aflb.tn@sushi.stanford.edu>
I would appreciate someone sending me a copy of the following paper:
Overmars, M. A O(1) average time update scheme for balanced binary
search trees, Bull. EATCS, 1982, pages 27-29.
Thanks in advance.
Paul Dietz
SDR
Ridgefield, CT 06877-4108
(dietz@sdr.slb.com)
∂09-Feb-88 0930 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu PODC88 Submissions - Maybe Erroneously Returned
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Feb 88 09:30:46 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 9 Feb 88 09:22:16-PST
Received: by lindy.stanford.edu; Tue, 9 Feb 88 09:27:04 PST
Received: by Forsythe.Stanford.EDU; Tue, 9 Feb 88 09:24:45 PST
Received: by BYUADMIN (Mailer X1.25) id 5143; Tue, 09 Feb 88 10:20:06 MST
Date: Tue, 9 Feb 88 10:19:46 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
DOLEV%ALMVMA.BITNET@forsythe.stanford.edu
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: DOLEV%ALMVMA.BITNET@forsythe.stanford.edu
Subject: PODC88 Submissions - Maybe Erroneously Returned
To: Local Distribution <aflb.tn@sushi.stanford.edu>
In the Call for Papers printed in CACM my name was misspelled twice,
once as DOLER and once as DOLEY. Unfortunately the mail-room here
returned submissions addressed to either of these names. Please resubmit
your papers to:
Danny Dolev
K53 Almaden Research Center
IBM Research
650 Harry Road
San Jose, CA 95120-6099
As a result of this we allow an extra week. The new deadline is Jan. 22nd.
Please circulate the announcement to those who may not get TheoryNet.
∂09-Feb-88 0936 AAAI-OFFICE@SUMEX-AIM.Stanford.EDU Executive Council Meeting
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Feb 88 09:36:15 PST
Date: Tue, 9 Feb 88 09:31:55 PST
From: AAAI <AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>
Subject: Executive Council Meeting
To: officers: ;
cc: aaaI-OFFICE@SUMEX-AIM.Stanford.EDU
Telephone: (415) 328-3123
Postal-Address: 445 Burgess Drive, Menlo Park, CA 94025
Message-ID: <12373388297.36.AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>
Some Council members have an expressed a request to hold the Council
meeting on Thursday afternoon, March 24 after the conclusion of the
Spring Symposium Series. This meeting will now occur from 1:00 pm
to the early evening in Room 352 in Margaret Jacks Hall (the same
building where the Computer Science Dept is), Stanford University.
Could you inform me if you will be able to make this meeting?
Thanks,
Claudia
-------
∂09-Feb-88 0941 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Change of address
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Feb 88 09:41:04 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 9 Feb 88 09:35:23-PST
Received: by lindy.stanford.edu; Tue, 9 Feb 88 09:39:57 PST
Received: by Forsythe.Stanford.EDU; Tue, 9 Feb 88 09:38:14 PST
Received: by BYUADMIN (Mailer X1.25) id 5525; Tue, 09 Feb 88 10:36:58 MST
Date: Tue, 9 Feb 88 10:23:18 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Thomas Lengauer <tl%pbinfo.uucp@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Thomas Lengauer <tl%pbinfo.uucp@forsythe.stanford.edu>
Subject: Change of address
To: Local Distribution <aflb.tn@sushi.stanford.edu>
I will be at XEROX PARC this year from February 26 to September 30. My
address there is:
Thomas Lengauer
XEROX PARC
3333 Coyote Hill Rd.
Palo Alto, CA 94304
U.S.A.
Telephone: (415) 494 4000
email:
lengauer.pa@xerox.com
Starting October, 1 I will again be in Paderborn.
-thomas lengauer
∂09-Feb-88 0944 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu COLOG-88: Preliminary Announcement
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Feb 88 09:44:23 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 9 Feb 88 09:36:23-PST
Received: by lindy.stanford.edu; Tue, 9 Feb 88 09:41:15 PST
Received: by Forsythe.Stanford.EDU; Tue, 9 Feb 88 09:39:49 PST
Received: by BYUADMIN (Mailer X1.25) id 5635; Tue, 09 Feb 88 10:38:52 MST
Date: Tue, 9 Feb 88 10:26:28 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Jeffery Zucker <zucker%cs.Buffalo.EDU@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Jeffery Zucker <zucker%cs.Buffalo.EDU@forsythe.stanford.edu>
Subject: COLOG-88: Preliminary Announcement
To: Local Distribution <aflb.tn@sushi.stanford.edu>
-------------------------------------------------------------------------
Preliminary announcement and call for papers
C O L O G - 88
INTERNATIONAL CONFERENCE ON COMPUTER LOGIC
December 12-16, 1988, Tallinn, Estonia, USSR
The aim of this conference is to establish scientific cooperation
in the field of computer logic. The presentation is in the form
of invited lectures (1 hour including discussion) and poster
sessions. Papers are invited in the following or related fields:
- applications of deductive systems
- dedctive program synthesis and analysis
- theorem proving
- computer experiments in logic-related fields
- logic programming
Chairman of the Program Committee is Per Martin-Lof (Sweden).
COLOG-88 will be held at the Institute of Cybernetics, Estonian
Academy of Sciences. Tallinn, old Hanseatic city, the capital of
Estonia, is situated at the Baltic Sea, 80 km from Helsinki, Finland,
and can be easily reached by boat from Helsinki.
Papers to be presented at poster sessions should arrive before
June 1, 1988, to
G. Mints
Institute of Cybernetics
Estonian Academy of Sciences
Akadeemia tee 21
Tallinn 200108
USSR
∂09-Feb-88 0953 GANGOLLI@Sushi.Stanford.EDU NO AFLB THIS WEEK
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Feb 88 09:51:25 PST
Date: Tue 9 Feb 88 09:43:40-PST
From: Anil R. Gangolli <GANGOLLI@Sushi.Stanford.EDU>
Subject: NO AFLB THIS WEEK
To: aflb.all@Sushi.Stanford.EDU
Office Phone: (415) 723-3605
Message-ID: <12373390436.30.GANGOLLI@Sushi.Stanford.EDU>
Because of the CSD computer forum Wednesday and Thursday of this week,
there will be NO AFLB meeting on Feb. 11. --anil.
-------
∂09-Feb-88 1002 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Complexity Day at Northeastern University
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Feb 88 10:02:50 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 9 Feb 88 09:53:17-PST
Received: by lindy.stanford.edu; Tue, 9 Feb 88 09:58:09 PST
Received: by Forsythe.Stanford.EDU; Tue, 9 Feb 88 09:53:38 PST
Received: by BYUADMIN (Mailer X1.25) id 5767; Tue, 09 Feb 88 10:52:08 MST
Date: Tue, 9 Feb 88 10:29:35 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
alan selman <selman%corwin.ccs.northeastern.edu@relay.cs.net>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: alan selman <selman%corwin.ccs.northeastern.edu@relay.cs.net>
Subject: Complexity Day at Northeastern University
To: Local Distribution <aflb.tn@sushi.stanford.edu>
-------------------------------------------------------------------------
College of Computer Science
Northeastern University
A Day of Structure in Complexity Theory
Friday, January 22, 1988
Join us for a day of talks given by members of the Program Committee
of the Third Annual Structure in Complexity Theory Conference.
Schedule of Events
10:00 a.m. Tim Long "One-Way Functions, Isomorphisms,
Ohio State and Complete Sets"
11:00 a.m. Juris Hartmanis "Collapsing Hierarchies"
Cornell University
12:00 noon Lunch Break
1:45 p.m. Uwe Schoening "Complexity Cores and Hard
EWH Koblenz Hard Problem Instances"
2:45 p.m. James Royer "Taking Advantage of Structure
U. Chicago in Complexity"
3:45 p.m. Ronald V. Book "Small Sets and Polynomial Time
UC, Santa Barbara Reducibilities"
All talks will take place at 356 Ell Center on the Northeastern
University campus.
PARKING ON CAMPUS WILL BE AVAILABLE BUT REQUIRES PRIOR APPROVAL.
If you will be driving, for information about visitor parking and
maps of campus, please contact:
Mrs. Gerry Hayes
College of Computer Science
Northeastern University
360 Huntington Ave.
Boston, MA 02115
(617) 437-2462
For other information please contact Alan Selman, (617)437-8688,
selman@corwin.ccs.northeastern.edu.
The Third Annual Structure in Complexity Theory Conference will
be held June 14 -17, 1988, at Georgetown University, Washington,
D.C. and is sponsored by the IEEE Computer Society Technical
Committee on Foundations of Computer Science, Georgetown Univer-
sity, and Northeastern University, in cooperation with EATCS and
ACM-SIGACT.
∂09-Feb-88 1011 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu WG88
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Feb 88 10:11:14 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 9 Feb 88 09:58:45-PST
Received: by lindy.stanford.edu; Tue, 9 Feb 88 10:03:36 PST
Received: by Forsythe.Stanford.EDU; Tue, 9 Feb 88 09:54:39 PST
Received: by BYUADMIN (Mailer X1.25) id 5812; Tue, 09 Feb 88 10:52:42 MST
Date: Tue, 9 Feb 88 10:32:43 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Jan van Leeuwen <jan%ruuinfvax.uucp@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Jan van Leeuwen <jan%ruuinfvax.uucp@forsythe.stanford.edu>
Subject: WG88
To: Local Distribution <aflb.tn@sushi.stanford.edu>
-------------------------------------------------------------------------
14th International Workshop
on
GRAPH-THEORETIC CONCEPTS IN COMPUTER SCIENCE (WG'88)
Amsterdam(NL), June 15-17, 1988
In the successful series of International Workshops on "Graph-theoretic
Concepts in Computer Science" (last held in Erlangen in 1987), the 14th
Workshop will be held at the Centre for Mathematics and Computer Science
in Amsterdam, June 15-17, 1988. The Workshop is intended to provide a
forum for researchers and other parties interested in the study and
application of GRAPH-THEORETIC CONCEPTS in computer science. Aim is to
present recent research results and to identify and explore directions for
future research.
Papers are solicited describing original results in the study and
application of graph-theoretic concepts in computer science, including
e.g. the design and analysis of graph algorithms, applied graph theory in
computer science, operations research algorithms on graphs and networks,
parallel and distributed algorithms on graphs, graph-theoretic modeling in
computer science (e.g. in hardware and software design), graph grammars and
graph replacement systems, graph-theoretic aspects of computer graphics
(e.g. in solid modeling and CAD), computational geometry, efficient data
structures and complexity-theoretic analyses, graph-theoretic aspects of
programming and communication structures, and related fields.
Intended contributors are invited to submit 7 copies of a detailed
abstract (10 pages or more) or draft paper to the organizational chairman
Prof Jan van Leeuwen
Department of Computer Science
University of Utrecht
Budapestlaan 6
P.O. Box 80.012
3508 TA Utrecht
the Netherlands
(email: mcvax!ruuinfvax!jan)
by MARCH 25, 1988. Notification of acceptance follows by APRIL 25, 1988. A
draft final copy of each accepted paper is due JUNE 1, 1988 in order that
all papers are available for participants at the Workshop. The official
proceedings of the Workshop will be published afterwards, in the series
Lecture Notes in Computer Science of Springer Verlag.
ORGANIZATIONAL COMMITTEE: Jan van Leeuwen (Utrecht), David W. Matula
(Dallas), Manfred Nagl (Aachen), Hartmut Noltemeier (Wuerzburg),
Hans-Juergen Schneider (Erlangen), Emo Welzl (Berlin), Shmuel Zaks
(Haifa).
FURTHER INFORMATION. The Workshop will be held at the "Centrum voor
Wiskunde en Informatica (CWI)", a national research facility (formerly
known as "the Mathematical Centre") located in Amsterdam, the Netherlands.
The CWI features a large library, lecture rooms, adjacent parks and
waters, easy parking etc. The Workshop participants will be housed in a
convenient nearby hotel (roomrates approx. 60 US dollars per day), with a
daily shuttle to and from the CWI. The registration fee for the Workshop
will be approximately 75 US dollars (not including lodging). The city of
Amsterdam is easily reached from all over the world and is well-known for
its many cultural attractions. Further details of the Workshop will be
announced in the final program. For further information, contact the
organizational chairman or Mrs Geraldine Leebeek (Dept of Computer
Science, University of Utrecht, P.O.Box 80.012, 3508 TA Utrecht, the
Netherlands, tel. +31-30-531454, email: mcvax!ruuinfvax!gerald).
∂09-Feb-88 1017 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Workshop on Specification and Verfication of Concurrent Systems
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Feb 88 10:17:33 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 9 Feb 88 10:02:23-PST
Received: by lindy.stanford.edu; Tue, 9 Feb 88 10:07:18 PST
Received: by Forsythe.Stanford.EDU; Tue, 9 Feb 88 10:04:28 PST
Received: by BYUADMIN (Mailer X1.25) id 5946; Tue, 09 Feb 88 10:59:46 MST
Date: Tue, 9 Feb 88 10:37:50 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Chic Rattray <cr%CS.STIR.AC.UK@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Chic Rattray <cr%CS.STIR.AC.UK@forsythe.stanford.edu>
Subject: Workshop on Specification and Verfication of Concurrent Systems
To: Local Distribution <aflb.tn@sushi.stanford.edu>
-------------------------------------------------------------------------
WORKSHOP ON
SPECIFICATION AND VERIFICATION
OF CONCURRENT SYSTEMS
6 - 8 July 1988
University of Stirling
Scotland
in conjunction with BCS-FACS
CALL FOR PAPERS
Specification and verification techniques are playing an increasingly
important role in the design and production of practical concurrent
systems. The wider application of these techniques serves to identify
difficult problems that require new approaches to their solution and
further developments in specification and verification. The Workshop
aims to capture this interplay by providing a forum for the exchange
of the experiences of academic and industrial experts in the field.
Papers are invited on: original research, practical experience with
methods, tools, and environments in any of the following or related
areas:
- object-oriented, process, data and logic based models and
specification methods for concurrent systems
- verification of concurrent systems
- tools and environments for the analysis of concurrent systems
- applications of specification languages to practical concurrent
system design and development.
The Workshop will include a number of talks by invited speakers. There
will be an opportunity for small group evening sessions on specialist
topics. Those interested in organising such sessions should contact the
address below.
If you wish to submit a paper, please send an abstract (approx. 1000 words)
by 29 February 1988. Notification of acceptance will be posted to the
authors by 30 March 1988; camera-ready copies of the full papers will be
required by 30 April 1988 so that the proceedings can be available at the
Workshop. Selected Workshop papers will be published in journals associated
with BCS-FACS.
The Workshop will be held in the MacRobert Centre, University of Stirling,
with accommodation provided in halls of residence. The Stirling campus,
one of the most attractive in Europe, is situated on the outskirts of
Stirling - the ancient capital of Scotland - and is within easy reach of
Edinburgh and Glasgow by road and rail.
Abstracts should be sent to:
Charles Rattray,
Department of Computing Science,
University of Stirling,
Stirling,
Scotland FK9 4LA.
∂09-Feb-88 1021 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu PODC88 Call For Papers
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Feb 88 10:21:21 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 9 Feb 88 10:03:09-PST
Received: by lindy.stanford.edu; Tue, 9 Feb 88 10:08:05 PST
Received: by Forsythe.Stanford.EDU; Tue, 9 Feb 88 10:05:42 PST
Received: by BYUADMIN (Mailer X1.25) id 5986; Tue, 09 Feb 88 11:00:31 MST
Date: Tue, 9 Feb 88 10:41:15 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Professor Jia Xu <CS100045%YUSOL.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Professor Jia Xu <CS100045%YUSOL.BITNET@forsythe.stanford.edu>
Subject: PODC88 Call For Papers
To: Local Distribution <aflb.tn@sushi.stanford.edu>
-------------------------------------------------------------------------
CALL FOR PAPERS
Seventh ACM SIGACT-SIGOPS Symposium on
Principles of Distributed Computing
(PODC88)
Toronto, Ontario, Canada
August 15-17, 1988
Original research contributions are sought that address fundamental issues
in the theory and practice of distributed and concurrent systems. Topics
of interest include, but are not limited to, the following aspects of
concurrent and distributed systems:
* Principles of distributed computation derived from
practical experience with working systems
* Algorithms and complexity Specification, semantics,
and verification
* Programming languages and programming language constructs
* Fault tolerance
Important Dates:
Jan. 15, 1987: Abstracts due.
Apr. 1, 1987: Authors informed of acceptance or rejection.
May 15, 1987: A final copy of each accepted paper due, typed
on special forms for inclusion in the conference
proceedings.
Please send twelve copies of a detailed abstract (not the complete paper),
with the address, telephone number, and "net address" (if available) of a
contact author on the cover page, to the Program Chair:
Danny Dolev
K53 Almaden Research Center
IBM Research
650 Harry Road
San Jose, CA 95120-6099
dolev@almvma.bitnet or dolev@ibm.com
The abstract must provide sufficient detail to allow the program committee
to assess the merits of the paper and should include appropriate
references to and comparisons with extant work. It is recommended that
each submission begin with a succinct statement of the problem, a summary
of the main results, and a brief explanation of the significance and
relevance to the conference's topic of the work, all suitable for a
nonspecialist. Technical development of the work, directed to the
specialist, should follow. A limit of 10 typed double-spaced pages is
placed on submissions. If the authors believe that more details essential
to prove the main claims of the paper, then they may include a clearly
marked appendix that will be read at the discretion of the Program
Committee.
Abstracts that deviate significantly from these guidelines, risk rejection
without consideration of their merits. Also, abstracts that are not
postmarked by the Jan. 15th deadline will not be considered.
Conference Chair: Eshrat Arjomandi, York University
CS100002@YUSOL or utzoo!yunexus!yetti!eshrat
Publicity Chair: Jia Xu, York University
utzoo!yunexus!yetti!jxu
The Program Committee:
Krzysztof Apt -CWI, Holland&Austin Alan Demers -XEROX PARC
Danny Dolev -Hebrew U.&IBM ARC Cynthia Dwork -IBM ARC
Michael Fischer -Yale Jim Gray -Tandem
Richard Ladner -Seattle Michael Merritt -AT&T
David Peleg -Stanford Ken Sevcik -Toronto
Pierre Wolper -Liege, Belgium Shmuel Zaks -Technion, Israel
∂09-Feb-88 1026 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for papers
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Feb 88 10:25:56 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 9 Feb 88 10:05:25-PST
Received: by lindy.stanford.edu; Tue, 9 Feb 88 10:09:59 PST
Received: by Forsythe.Stanford.EDU; Tue, 9 Feb 88 10:08:36 PST
Received: by BYUADMIN (Mailer X1.25) id 6025; Tue, 09 Feb 88 11:01:01 MST
Date: Tue, 9 Feb 88 10:47:49 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Lenny Pitt <pitt%p.cs.uiuc.edu@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Lenny Pitt <pitt%p.cs.uiuc.edu@forsythe.stanford.edu>
Subject: Call for papers
To: Local Distribution <aflb.tn@sushi.stanford.edu>
---------------------------------------------------------------------------
CALL FOR PAPERS
Workshop on Computational Learning Theory
Cambridge, Massachusetts
August 3-5, 1988
The first workshop on Computational Learning Theory will be
held at MIT August 3-5, 1988. It is expected that most papers will
consist of rigorous and formal analyses of theoretical issues in
Machine Learning. Empirical work will be considered only if it is
testing some hypothesis that has a quantitative theoretical basis.
Possible topics include, but are not limited to:
1. resource, convergence-rate and robustness analysis (time, space,
number of examples, noise sensitivity, etc.) of specific learn-
ing algorithms,
2. general learnability and non-learnability results in existing
computational learning models and general upper and lower bounds
on resources required for learning, and
3. new computational learning models, extensions of existing learn-
ing models, and theoretical comparisons among learning models.
Papers that make formal connections with work in Robotics,
Neural Nets, Pattern Recognition, Adaptive Signal Processing and
Cryptography are also welcome.
TO REGISTER FOR THE WORKSHOP
Due to space limitations, registration for the workshop will
be limited to 60. If you would like to participate, send a brief
(one page max.) description of your current research, by April 15,
to the address below. Participants will be notified, and sent
registration information, by June 1. It is possible that some
financial support will be available for graduate student partici-
pants.
TO SUBMIT A PAPER
Authors should submit extended abstracts that consist of:
(1) A cover page with title, author's names and addresses (e-mail
also if possible), and a 200 word summary.
(2) A body not exceeding 5 pages in twelve-point font. A brief
statement of the definitions and model used followed by a list
of theorems with proof sketches is suggested. A succinct
statement on the significance of the results should also be
included.
Authors should send 8 copies of their submissions to
John Cherniavsky
Workshop on Computational Learning Theory
Department of Computer Science
Georgetown University
Washington, D.C. 20057
The deadline for receiving submissions is April 15, 1988.
This deadline is FIRM. Authors will be notified by June 1, final
camera-ready papers will be due July 1.
Organizing/program committee:
David Haussler, UC Santa Cruz, (workshop co-chair);
Leonard Pitt, U. Illinois, (workshop co-chair);
John Cherniavsky, Georgetown University, (program committee chair);
Ronald Rivest, MIT, (local arrangements);
Dana Angluin, Yale University;
Carl Smith, NSF;
Leslie Valiant, Harvard University;
Manfred Warmuth, UC Santa Cruz.
∂09-Feb-88 1034 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu PODS88 Program
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Feb 88 10:34:09 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 9 Feb 88 10:15:04-PST
Received: by lindy.stanford.edu; Tue, 9 Feb 88 10:19:14 PST
Received: by Forsythe.Stanford.EDU; Tue, 9 Feb 88 10:17:45 PST
Received: by BYUADMIN (Mailer X1.25) id 6269; Tue, 09 Feb 88 11:13:18 MST
Date: Tue, 9 Feb 88 10:51:28 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Mihalis Yannakakis <mihalis%research@att.arpa>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Mihalis Yannakakis <mihalis%research@att.arpa>
Subject: PODS88 Program
To: Local Distribution <aflb.tn@sushi.stanford.edu>
-------------------------------------------------------------------------
Seventh ACM SIGACT-SIGMOD-SIGART Symposium
on
PRINCIPLES OF DATABASE SYSTEMS
Austin, Texas, March 21-23, 1988
INFORMATION
LOCATION
The 7th ACM Symposium on Principles of Database Systems will be held at
The Driskill, situated in downtown Austin in the heart of the entertainment
district. The Driskill Hotel, a Historical Landmark, combines 19th-century
atmosphere with 20th-century amenities.
Checkout time is noon; checkin time is 3pm, or earlier subject to
room availability. A block of rooms has been reserved until March 5th, 1988.
Please reserve a room by using the form provided or by calling 800-252-9367.
Room rates and availability are not guaranteed past March 5th.
REGISTRATION
Advanced registration is requested using the form provided. Registration rates
go up markedly after March 8th. A registration desk will be open Sunday
night from 7:30pm to 10:00pm, and during the day on Monday (8:30 am to 4:30 pm).
Registrants, other than students, receive admission to the technical sessions,
one copy of the proceedings, reception, lunches, and a Texas Barbeque on Tuesday
evening. Student registration, available to full-time students only, includes
the technical sessions and one copy of the proceedings. Additional copies of
the proceedings will be available for sale at the registration desk.
TRANSPORTATION
There are two choices for ground transportation from the airport to the hotel.
The Driskill provides complimentary airport transportation, which can be
summoned by a dedicated phone in the airport terminal or greeted personally if
arrival times are provided. Additionally, taxi fare to the hotel is about $5.
For participants driving to The Driskill, take IH35 south, then exit at
6th St. heading west. Valet parking is available at the main entrance at
604 Brazos, between 6th and 7th Streets.
CLIMATE
Normal daily temperatures in Austin in March range from 58 to 79 degrees F.
Measurable rain, usually in the form of thundershowers, can be expected on one
day in four. Occasional cold fronts bring northerly winds and sharp drops in
temperature, but cold spells seldom last more than two days. Expect to see most
trees and flowers in bloom.
EVENT LOCATION
All technical sessions, reception, lunches, and business meeting will be held
off the Mezzanine of The Driskill Hotel. On Tuesday night
there will be an excursion to find authentic Texas Barbeque. Buses will leave
the hotel at 6pm and return by 9pm.
------------------------------------------------------------------------------
TECHNICAL PROGRAM
SUNDAY, MARCH 20, 1988
Reception: 7:30 pm - 10:00 pm, Mezzanine
MONDAY, MARCH 21, 1988
Note: All talks will take place in the Crystal Ballroom
SESSION 1: 9:00 am - 10:30 am
Chair: Mihalis Yannakakis (AT&T Bell Laboratories)
Invited Talk: Theory of Database Queries,
Ashok K. Chandra (IBM T. J. Watson Research Center)
On the Expressive Power of Logic Programming Languages with Sets,
Gabriel M. Kuper (IBM T.J. Watson Research Center)
Rewriting of Rules Containing Set Terms in a Logic Data Language (LDL),
Oded Shmueli, Shalom Tsur and Carlo Zaniolo (MCC)
Coffee Break: 10:30 am - 11:00 am
SESSION 2: 11:00 am - 12:30 pm
Chair: Ronald Fagin (IBM Almaden Research Center)
Possibilities and Limitations of Using Flat Operators
in Nested Algebra Expressions, Jan Paredaens (University of Antwerp)
and Dirk Van Gucht (Indiana University)
On the Expressive Power of Database Queries with Intermediate Types,
Richard Hull and Jianwen Su (University of Southern California)
An Axiomatic Approach to Deciding Query Safety in Deductive Databases,
Michael Kifer (SUNY at Stony Brook), Raghu Ramakrishnan (University of
Wisconsin-Madison), and Avi Silberschatz (University of Texas at Austin)
Temporal Deductive Databases and Infinite Objects,
Jan Chomicki and Tomasz Imielinski (Rutgers University)
Lunch: 12:30 pm - 2:00 pm
SESSION 3: 2:00 pm - 3:30 pm
Chair: Alberto Mendelzon (University of Toronto)
The Complexity of Ordering Subgoals,
Jeffrey D. Ullman (Stanford University)
and Moshe Y. Vardi (IBM Almaden Research Center)
An Algorithm for Ordering Subgoals in NAIL!,
Katherine A. Morris (Stanford University)
Optimizing Existential Datalog Queries,
Raghu Ramakrishnan (University of Wisconsin-Madison),
Catriel Beeri (Hebrew University and MCC), and Ravi Krishnamurthy (MCC)
Explicit Control of Logic Programs Through Rule Algebra,
Tomasz Imielinski (Rutgers University) and Shamim Naqvi (MCC)
Coffee Break: 3:30 pm - 4:00 pm
SESSION 4: 4:00 pm - 5:30 pm
Chair: Henry Korth (University of Texas at Austin)
Analysis of Bounded Disorder File Organization,
M. V. Ramakrishna and P. Mukhopadhyay (Michigan State University)
Analytical Modeling of Materialized View Maintenance,
Jaideep Srivastava and Doron Rotem (University of California, Berkeley)
Serialization Graph Algorithms for Multiversion Concurrency Control,
Thanasis Hadzilacos (CTI Patras)
The Queue Protocol: a Deadlock-Free, Homogeneous, Non-Two-Phase Locking Protocol
Udo Kelter (University of Dortmund)
Business Meeting: 8:30 pm - 10:00 pm, Mezzanine
TUESDAY, MARCH 22, 1988
SESSION 5: 9:00 pm - 10:30 pm
Chair: Victor Vianu (University of California, San Diego)
Invited Talk: Object-Oriented Database Systems,
Francois Bancilhon (INRIA)
Independence-Reducible Database Schemes,
Edward P. F. Chan (University of Waterloo),
and Hector J. Hernandez (Texas A&M University)
Decomposition of Relational Schemata into Components Defined
by Both Projection and Restriction,
Stephen J. Hegner (University of Vermont)
Coffee Break: 10:30 am - 11:00 am
SESSION 6: 11:00 am - 12:30 pm
Chair: Daniel J. Rosenkrantz (SUNY at Albany)
Concepts for a Database System Synthesizer,
D. S. Batory (University of Texas at Austin)
Transaction Synchronisation in Object Bases,
Thanasis Hadzilacos (CTI Patras) and Vassos Hadzilacos (University of Toronto)
Hybrid Concurrency Control for Abstract Data Types,
Maurice P. Herlihy (Carnegie Mellon University) and William E. Weihl (MIT)
Concurrent Set Manipulation without Locking,
Vladimir Lanin and Dennis Shasha (New York University)
Lunch: 12:30 pm - 2:00 pm
SESSION 7: 2:00 pm - 3:30 pm
Chair: Krzysztof Apt (CWI Amsterdam and University of Texas at Austin)
Unfounded Sets and Well-founded Semantics for General Logic Programs,
Allen Van Gelder (University of California at Santa Cruz),
and Kenneth Ross (Stanford University)
Why not Negation by Fixpoint?,
Phokion G. Kolaitis (Stanford University),
and Christos H. Papadimitriou (University of California, San Diego)
Procedural and Declarative Database Update Languages,
Serge Abiteboul (INRIA) and Victor Vianu (University of California, San Diego)
Database Updates in Logic Programming,
Shamim Naqvi and Ravi Krishnamurthy (MCC)
Coffee Break: 3:30 pm - 4:00 pm
SESSION 8: 4:00 pm - 5:30 pm
Chair: Avi Silberschatz (University of Texas at Austin)
Optimization of Multiple-Relation Multiple-Disjunct Queries,
M. Muralikrishna and David J. De Witt (University of Wisconsin, Madison)
Statistical Estimators for Relational Algebra Expressions,
Wen-Chi Hou, Gultekin Ozsoyoglu and Baldeo K. Taneja
(Case Western Reserve University)
Stable Set and Multiset Operations in Optimal Time and Space,
Bing-Chao Huang and Michael A. Langston (Washington State University)
Minimizing Time-Space Cost for Database Version Control,
Lin Yu and Daniel J. Rosenkrantz (SUNY at Albany)
Texas Barbeque: 6 pm - 9 pm
Meet the buses in the lobby
WEDNESDAY, MARCH 23, 1988
SESSION 9: 9:00 am - 10:30 am
Chair: Serge Abiteboul (INRIA)
Invited Talk: What Should a Database Know?,
Raymond Reiter (University of Toronto)
A Semantics for Complex Objects and Approximate Queries,
Peter Buneman, Susan Davidson and Aaron Watters (University of Pennsylvania)
A Framework for Comparison of Update Semantics,
Marianne Winslett (Stanford University)
Coffee Break: 10:30 am - 11:00 am
SESSION 10: 11:00 am - 12:10 pm
Chair: Paris Kanellakis (Brown University)
A Generalized Transitive Closure for Relational Queries,
Seppo Sippu (University of Jyvaskyla)
and Eljas Soisalon-Soininen (University of Helsinki)
Counting Methods for Cyclic Relations,
Ramsey W. Haddad (Stanford University)
and Jeffrey F. Naughton (Princeton University)
Decidability and Undecidability Results for Boundedness
of Linear Recursive Queries,
Moshe Y. Vardi (IBM Almaden Research Center)
-------------------------------------------------------------------------------
CONFERENCE ORGANIZATION
Sponsors: SIGACT, SIGMOD, and SIGART
Executive Committee: A. K. Chandra, A. Silberschatz, M. Y. Vardi, M. Yannakakis
Chairman: Avi Silberschatz, Dept. of Computer Sciences,
University of Texas at Austin, Austin, Texas 78712,
(512) 471-9706, avi@sally.utexas.edu
Program Chairman: Mihalis Yannakakis, AT&T Bell Laboratories,
600 Mountain Avenue, Murray Hill, NJ 07974,
(201) 582-2198, mihalis@research.att.com
Local Arrangements: Chris Edmondson-Yurkanan, Dept. of Computer Sciences,
University of Texas at Austin, Austin, Texas 78712,
(512) 471-9546, dragon@sally.utexas.edu
Program Committee: S. Abiteboul, K. Apt, P. Bernstein, P. Kanellakis,
D. Maier, A. Mendelzon, D. Skeen, V. Vianu, M. Yannakakis
-------------------------------------------------------------------------------
ADVANCE REGISTRATION FORM, ACM-PODS
Please send this form or a facsimile along with a money order or check
(payable to 7th ACM SYMPOSIUM ON PRINCIPLES OF DATABASE SYSTEMS) to:
ACM-PODS Registration
c/o Chris Edmondson-Yurkanan
Dept. of Computer Sciences
Taylor Hall 2.124
University of Texas at Austin
Austin, Texas 78712-1188
(before Mar. 8) (After)
ACM and SIG member $180 $240
ACM member only 190 250
SIG member only 190 250
Nonmember 225 290
Student 50 60
Requests for refunds will be honored until March 8, 1988.
Name_____________________________________________________
Affiliation______________________________________________
City_____________________State______________Zip__________
Country_______________________Telephone__________________
Net Address______________________________________________
_____ Check here if confirmation of registration is required.
Dietary restrictions: _______Kosher _______Vegetarian
Special meals can be guaranteed only for those who register in advance.
_______________________________________________________________________
HOTEL RESERVATION FORM, ACM-PODS March 1988
Please mail this form or a facsimile (being sure to mention the ACM-PODS
Conference) by March 5 to:
The Driskill
604 Brazos
Austin, Texas 78701
Tel: (512) 474-5911
or (800) 252-9367
Accomodations desired:
_____Single $55
_____Double $60
_____Triple $60
_____Quad $60
Arrival date_____________________________________Time__________________________
Departure date___________________________________Time__________________________
Name___________________________________________________________________________
Sharing room with______________________________________________________________
Address________________________________________________________________________
City_______________________________State__________________Zip__________________
Country________________________________________________________________________
All rooms will be held until 4pm the day of arrival without deposit/guarantee.
For arrivals later than 4pm please guarantee to a major credit card:
_____Amer. Express _____VISA _____Mastercard _____Diners _____Discover
Credit Card number____________________________________________________________
Exp. Date_____________________________________________________________________
Signature_____________________________________________________________________
______________________________________________________________________________
∂10-Feb-88 1447 ullman@navajo.stanford.edu paper received
Received: from navajo.stanford.edu by SAIL.Stanford.EDU with TCP; 10 Feb 88 14:47:51 PST
Received: by navajo.stanford.edu; Wed, 10 Feb 88 14:40:53 PST
Date: Wed, 10 Feb 88 14:40:53 PST
From: Jeff Ullman <ullman@navajo.stanford.edu>
Subject: paper received
To: nail@navajo.stanford.edu
"An efficient labelling algorithm for magic set computation
on stratified databases,"
I. Balbin, K. Meenakshi, and K. Ramamohanarao,
TR 88/1, U. Melbourne
The problem is that when we have a stratified KB, and we try to
apply a magic sets transformation, we may wind up with a nonstratified KB.
A previous paper by Balbin, Port, and Ramam... proposed "labeling"
(well "labelling") as a way to avoid the problem.
One places subscripts (labels) on different occurrences of the same
predicate, say p, in the bodies of the rules.
Having, say, split p into p_1 and p_2, we make two copies of the
rules for p [[after having labeled the p's in the bodies]]
and label the heads of one set p_1, the other p_2.
This paper proposes a way to do labeling in a way that makes
the rules stratified after the MS transformation, and yet minimizes
the number of rule duplications.
********************************
New thought: There are transformations on rules such as the
labeling described above, or "expansion," where we replace an
occurrence of an IDB subgoal by the bodies of its rules, e.g.
anc(X,Y) :- par(X,Y).
anc(X,Y) :- par(X,Z) & anc(Z,Y).
could become
anc(X,Y) :- par(X,Y).
anc(X,Y) :- par(X,Z) & par(Z,Y).
anc(X,Y) :- par(X,Z) & par(Z,W) & anc(W,Y).
Question: when does a transformation guarantee to improve (or not
degrade) the performance of a specific algorithm, e.g., magic sets,
or memoing? When is it guaranteed NOT to improve performance?
---jeff
∂10-Feb-88 1706 TAJNAI@Score.Stanford.EDU You are Invited to the Forum Reception Thursday, 4:30-6, FAculty Club
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Feb 88 17:06:25 PST
Date: Wed 10 Feb 88 16:56:41-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: You are Invited to the Forum Reception Thursday, 4:30-6, FAculty Club
To: csd.list@Score.Stanford.EDU
Message-ID: <12373731407.51.TAJNAI@Score.Stanford.EDU>
Faculty, Staff, Students, and Friends
of the
Computer Science Department
and the
Computer Systems Laboratory
are invited to
attend the
Stanford Computer Forum Reception
which closes our
Twentieth Annual Conference
Faculty Club -- Red and Gold Lounges
Thursday, February 11, 1988
4:30 - 6:00pm
-------
-------
∂10-Feb-88 1721 CBARSALOU@Score.Stanford.EDU
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Feb 88 17:21:07 PST
Date: Wed 10 Feb 88 17:04:17-PST
From: Caroline Barsalou <CBARSALOU@Score.Stanford.EDU>
To: csd-list@Score.Stanford.EDU
Message-ID: <12373732789.44.CBARSALOU@Score.Stanford.EDU>
Attention !! Deadline !!
Caroline
---------------
Subject: W-4 exempt status
From the Controller's Office:
"This is a reminder that persons who wish to renew their W-4 exempt
status must do so before Feb. 15, 1988. Employees should fill out
a new SU-32 (Tax Data Form) and send it to the Payroll Department
by Feb. 12, 1988 to make our deadline. Please notify any students
who work for you that their exemption will be removed on February 15."
I know the forms are available at Payroll and here at the receptionnist's
desk.
-------
∂10-Feb-88 1756 @Score.Stanford.EDU:MYERS@Sushi.Stanford.EDU Winter Quarter Potluck
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Feb 88 17:55:59 PST
Received: from Sushi.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 10 Feb 88 17:49:54-PST
Date: Wed 10 Feb 88 17:50:47-PST
From: Karen L. Myers <MYERS@Sushi.Stanford.EDU>
Subject: Winter Quarter Potluck
To: faculty@Score.Stanford.EDU
Message-ID: <12373741257.11.MYERS@Sushi.Stanford.EDU>
It has become a tradition within the department to hold a
Winter Quarter potluck every year. In the past, these events have been
hosted by faculty members who have graciously volunteered their homes
for an evening.
Plans are underway to continue with the traditional potluck,
but a location for this year's event has not yet been found. If you
are interested in serving as this year's host, please let me know.
The only timing constraint is that the potluck should take place some
time before the start of the Examination Period (March 14). As the
organizational details of the event will all be handled by the student
Social Committee, the inconvenience to the host should be kept to a
minimum. Thanks!
Karen Myers & Paul Edwards
Social Committee
-------
∂10-Feb-88 2009 emma@alan.stanford.edu CSLI Calendar, February 11, 3:17
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 10 Feb 88 20:09:22 PST
Received: from alan.stanford.edu by russell.stanford.edu (3.2/4.7); Wed, 10 Feb 88 19:22:40 PST
Received: by alan.stanford.edu (3.2/4.7); Wed, 10 Feb 88 19:23:49 PST
Date: Wed, 10 Feb 88 19:23:49 PST
From: emma@alan.stanford.edu (Emma Pease)
To: friends@alan.stanford.edu
Subject: CSLI Calendar, February 11, 3:17
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
11 February 1988 Stanford Vol. 3, No. 17
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 11 February 1988
12 noon TINLunch
Ventura Hall Reading: "Default Reasoning, Nonmonotonic Logics,
Conference Room and the Frame Problem"
by Steve Hanks and Drew McDermott
Discussion led by Hideyuki Nakashima
(nakashim@csli.stanford.edu)
Abstract in last week's Calendar
2:15 p.m. CSLI Seminar
Room G-19 A Type-free Theory of Types and Propositions
Redwood Hall Jon Barwise
(barwise@csli.stanford.edu)
Abstract in last week's Calendar
3:30 p.m. Tea
Ventura Hall
--------------
CSLI ACTIVITIES FOR NEXT THURSDAY, 18 February 1988
12 noon TINLunch
Ventura Hall Reading: "The Limits of AI"
Conference Room by J. T. Schwartz
Discussion led by Jerry Hobbs
(hobbs@warbucks.ai.sri.com)
Abstract below
2:15 p.m. CSLI Seminar
Room G-19 Intelligent, Communicating Agents
Redwood Hall Nils Nilsson
(nilsson@score.stanford.edu)
Abstract below
3:30 p.m. Tea
Ventura Hall
--------------
NEXT WEEK'S TINLUNCH
Reading: "The Limits of AI"
by J. T. Schwartz
Discussion led by Jerry Hobbs
Hobbs@warbucks.ai.sri.com
February 18
In this paper, Schwartz examines AI critically from the perspective of
a mathematician and a hard computer scientist. He admits that
algorithmic specificity could overcome the 1,000,000:1 advantage the
brain has over near-future computers in computational power. But he
feels that mainstream AI technology based on search and
theorem-proving has not made a dent in the combinatorial explosion,
and hence has not achieved this algorithmic specificity. He argues
that the only real successes in AI have been in peripheral areas where
features of the specific problem can be exploited and more classical
mathematics can be applied.
--------------
NEXT WEEK'S SEMINAR
Intelligent, Communicating Agents
Nils J. Nilsson
(nilsson@score.stanford.edu)
Department of Computer Science
Stanford University
February 18
Research in artificial intelligence (AI) has concentrated largely on
systems that are able to reason about specialized topics. Typical
examples are expert systems. Except for work in robotics, AI
researchers have not yet paid much attention to connecting their
reasoning systems to the physical world, and robotics work to date has
not focused on high-level reasoning. We examine the special problems
encountered when the computational chain from sensory perception to
effector action is forced to go through a reasoning system (as it
sometimes must if the system is to perform appropriately in complex
environments). We are concerned especially with designing intelligent
systems that must function in environments in which there are other
active entities---entities complex enough that it is best to consider
them as "agents" having beliefs, goals, and intentions. A central
problem in such research concerns the communicative acts engaged in by
such agents.
There will be a series of three lectures. The first, by Nilsson,
will give an overview of the ICA project and will discuss some of the
approaches being taken in designing the overall architecture of these
agents.
--------------
NEW LECTURE NOTES
Two new titles in the CSLI Lecture Notes series have recently been
published. The first, by David Hilbert, is entitled "Color and Color
Perception: A Study in Anthropocentric Realism." A brief description
of the book appears below. "Natural Language Processing in the 1980s:
A Bibliography" (ed. Gerald Gazdar et al.) is the second volume.
This book contains over 1,700 entries and an introduction, as well as
two indexes, one to keywords, the other to second and subsequent
authors. An online version of this bibliography can be found on
Russell, and, according to Jeff Goldberg, "It is possible to search
this bibliography automatically by computer mail." As he points out,
"Mail to clbib@russell.stanford.edu with the word `help' as the
Subject line of your message for details. Most questions you may have
are likely to be answered in that file. Mail to
clbib-request@russell.stanford.edu
to report bugs in the program that handles the automatic searching."
Both titles are distributed by the University of Chicago Press and
may be ordered directly (5801 Ellis Avenue, Chicago, Illinois 60637)
or purchased at the Stanford University Bookstore.
Color and Color Perception
ISBN 0--937073--16--4 (Paper) $11.95
ISBN 0--937073--15--6 (Cloth) $24.95
Natural Language Processing in the 1980s
ISBN 0--937073--28--8 (Paper) $11.95
ISBN 0--937073--26--1 (Cloth) $29.95
Color and Color Perception
Color has often been supposed to be a subjective property, a property
to be analyzed correctly in terms of the phenomenological aspects of
human experience. In contrast with subjectivism, an objectivist
analysis of color takes color to be a property objects possess in
themselves, independently of the character of human perceptual
experience. David Hilbert defends a form of objectivism that
identifies color with a physical property of surfaces---their spectral
reflectance.
This analysis of color is shown to provide a more adequate account
of the features of human color vision than its subjectivist rivals.
The author's account of color also recognizes that the human
perceptual system provides a limited and idiosyncratic picture of the
world. These limitations are shown to be consistent with a realist
account of color and to provide the necessary tools for giving an
analysis of common-sense knowledge of color phenomena.
--------------
OTHER NEW PUBLICATIONS
The Sixth West Coast Conference on Formal Linguistics Proceedings
(WCCFL6) volume has just appeared. It is available at the Stanford
University Bookstore or may be purchased by writing to the CSLI
Publications office at Ventura Hall. (ISBN 0-937073-31-8; 352 pp.;
$12.00) This volume contains twenty-four papers presented at the 1987
WCCFL held at the University of Arizona. WCCFL proceedings are
published by the Stanford Linguistic Association.
∂11-Feb-88 0900 LOGMTC-mailer two events
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 11 Feb 88 09:00:10 PST
Received: from alan.stanford.edu by russell.stanford.edu (3.2/4.7); Thu, 11 Feb 88 09:03:18 PST
Received: from localhost by alan.stanford.edu (3.2/4.7); Thu, 11 Feb 88 09:04:27 PST
To: logic@alan.stanford.edu
Subject: two events
Date: Thu, 11 Feb 88 09:04:24 PST
From: Jon Barwise <barwise@alan.stanford.edu>
TOday there are two logic related events at CSLI. There is a TINLunch
discussion about nonmonotoic logic and default reasoning, at noon in
the conference room in Ventura Hall. At 2:15 I am giving a talk about
a new theory of types and propositions. This talk is in room G19 of
Redwood Hall.
∂11-Feb-88 1047 HEMENWAY@Score.Stanford.EDU A Few Important Things
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Feb 88 10:46:56 PST
Date: Thu 11 Feb 88 10:39:16-PST
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: A Few Important Things
To: phd-adm@Score.Stanford.EDU
Message-ID: <12373924845.22.HEMENWAY@Score.Stanford.EDU>
We have scheduled the Round 1 meeting for Tuesday, February 23 from
2:30- finish (most likely in MJH 252 but I will confirm later). It is
then that we will decide on both Early Admits and the applicants who
will progress to Round 2.
You may note that some applications you will receive in this batch
(and the next) are not absolutely complete. We have begun to
circulate applications that are missing 1 letter of recommendation and
I have also included one or two very strong applications which are
missing Dec. '87 GRE subject test scores (for some unknown reason we
still have not gotten all of them in).
A completely unforseen circumstance has prompted me to ask you for a
small favor, namely, that, if at all possible, you return this next
batch before Tuesday. I have just found out that I must have
arthroscopic surgery on my knee next Tuesday which will leave Lynn
alone to enter the ratings from batch 3 and generate the sets for
batch 4. I will be in on Monday and as many ratings as I can enter
then will mean that much less that must all be done on Tuesday. Feel
free to leave the packet of folders outside my office door if you
complete them and are here over the weekend.
Thank you for your help.
--Sharon
-------
∂11-Feb-88 1137 DEWERK@Score.Stanford.EDU Course Notes
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Feb 88 11:36:53 PST
Date: Thu 11 Feb 88 11:29:44-PST
From: Gerda de Werk <DEWERK@Score.Stanford.EDU>
Subject: Course Notes
To: instructors@Score.Stanford.EDU, tas@Score.Stanford.EDU
cc: dewerk@Score.Stanford.EDU
Message-ID: <12373934030.31.DEWERK@Score.Stanford.EDU>
This message is to remind you of the Department's course notes
policies, and to request a status report of your course's copying
charge reimbursements.
The first fifty pages of handouts are free of charge. After the first
fifty pages, students (including TV students and auditors) are charged
3cents per page for copies other than homework assignments, sample
solutions, and exams.
I would appreciate receiving the following information as soon as possible:
Course No.:
Number of on-campus students:
Number of TV students:
Number of auditors:
Estimated copies per student for quarter:
Amount charging students:
Number of students who have paid:
How you plan to collect from students who haven't paid yet:
Thank you in advance for your cooperation.
-Gerda
-------
∂11-Feb-88 1339 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu "what is a good hash function for this problem"
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Feb 88 13:39:35 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Thu 11 Feb 88 13:30:57-PST
Received: by lindy.stanford.edu; Thu, 11 Feb 88 13:37:05 PST
Received: by Forsythe.Stanford.EDU; Thu, 11 Feb 88 13:35:38 PST
Received: by BYUADMIN (Mailer X1.25) id 7618; Thu, 11 Feb 88 14:35:12 MST
Date: Thu, 11 Feb 88 14:50:13 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Bruce G. Greenblatt" <codas!killer!usl!bgg%bikini.cis.ufl.edu@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Bruce G. Greenblatt" <codas!killer!usl!bgg%bikini.cis.ufl.edu@forsythe.stanford.edu>
Subject: "what is a good hash function for this problem"
To: Local Distribution <aflb.tn@sushi.stanford.edu>
I have written my own little program to compute the input semigroups
of Finite State Automata, and in the program I hash on vectors of length
n, where each element of the vector is an integer between 1 and n.
The hash function I use now seems to be marginally OK, but I was hoping
someone had a suggestion for a wonderful hash function that distributed
these vectors around the hash table. Any suggestions ?
∂11-Feb-88 1630 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu MULIPLE ERROR ON PODC88 MESSAGES
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Feb 88 16:30:18 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Thu 11 Feb 88 16:22:48-PST
Received: by lindy.stanford.edu; Thu, 11 Feb 88 16:28:47 PST
Received: by Forsythe.Stanford.EDU; Thu, 11 Feb 88 16:26:31 PST
Received: by BYUADMIN (Mailer X1.25) id 0019; Thu, 11 Feb 88 17:25:58 MST
Date: Thu, 11 Feb 88 17:47:33 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
DOLEV%ALMVMA.BITNET@forsythe.stanford.edu
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: DOLEV%ALMVMA.BITNET@forsythe.stanford.edu
Subject: MULIPLE ERROR ON PODC88 MESSAGES
To: Local Distribution <aflb.tn@sushi.stanford.edu>
Please ignore previous PODC88 messages. They have been sent about
a month ago, and are completely out of date. We are now well
past the deadline for submission.
∂11-Feb-88 1644 @Score.Stanford.EDU:rav@Pescadero.stanford.edu FORUM reception
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Feb 88 16:44:47 PST
Received: from Pescadero by SCORE.STANFORD.EDU with TCP; Thu 11 Feb 88 16:10:40-PST
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA04699; Thu, 11 Feb 88 16:15:55 PST
Date: Thu, 11 Feb 88 16:15:55 PST
From: "Richard Vaughan" <rav@pescadero.stanford.edu>
Message-Id: <8802120015.AA04699@Pescadero>
To: csd.list@score.stanford.edu, csl-everyone@sierra.stanford.edu
Subject: FORUM reception
The Forum reception is taking place NOW at the Faculty Club.
All faculty, students, and staff are invited.
∂11-Feb-88 2035 REGES@Score.Stanford.EDU leaving Stanford
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Feb 88 20:34:55 PST
Date: Thu 11 Feb 88 20:22:47-PST
From: Stuart Reges <REGES@Score.Stanford.EDU>
Subject: leaving Stanford
To: csd-list@Score.Stanford.EDU
Office: CS-TAC 22, 723-9798
Message-ID: <12374031069.15.REGES@Score.Stanford.EDU>
Friends,
I'm sorry to say that I am leaving Stanford. NeXT Computers has an exciting
opportunity for me to pull together developer education, technical support,
and interaction with faculty. Most of you know that I'm a restless person.
When Gene Golub offered me my job six years ago I refused to promise to stay
more than a year. But it turned out that I found many places to wander inside
the department and the University. Even so, I'm feeling restless again and
although I love the work I'm doing, I am eager for new challenges.
My exit will be somewhat painful for everybody, but I will work hard with Nils
to make it as smooth as possible. Nils will be announcing his plans for the
transition once we've had a chance to talk it through. I will be spending some
time at NeXT right away, but I'll be spending most of my time here through the
end of March. Starting April 1st I'll be full-time at NeXT, but I will still
be hanging around. Steve Jobs has agreed to the idea of having me come down
one day a week indefinitely. I hope that I can continue to participate in what
this department is doing and I hope we can find projects of mutual interest.
For example, I'm hoping I can work out an arrangement where we would teach
classes like CS106 on NeXT machines with an educational Pascal that my staff at
NeXT would develop in collaboration with the intro instructors.
In any event, I'm sad to be leaving and I'll miss you all.
-------
∂11-Feb-88 2105 LOGMTC-mailer Logic Seminar
Received: from russell.stanford.edu by SAIL.Stanford.EDU with TCP; 11 Feb 88 21:05:10 PST
Received: by russell.stanford.edu (3.2/4.7); Thu, 11 Feb 88 21:08:21 PST
Date: Thu 11 Feb 88 21:08:19-PST
From: Sol Feferman <SF@Russell.Stanford.EDU>
Subject: Logic Seminar
To: Logic@russell.stanford.edu
Message-Id: <571640899.0.SF@Russell.Stanford.EDU>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@Russell.Stanford.EDU>
Speaker: Dr. Susumu Hayashi, Res. Inst. for Math Sciences, Kyoto University
(on leave to Dept. of Comp. Sci., Edinburgh University)
Title: PX: A computational logic
Time: Tuesday, Feb. 16, 4:15-5:30 PM
Place: Room 381-T, Math. Bldg., Stanford
S. Feferman
-------
∂11-Feb-88 2312 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Princeton Forum on Algorithms and Complexity
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Feb 88 23:12:52 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Thu 11 Feb 88 23:05:44-PST
Received: by lindy.stanford.edu; Thu, 11 Feb 88 23:11:53 PST
Received: by Forsythe.Stanford.EDU; Thu, 11 Feb 88 23:10:11 PST
Received: by BYUADMIN (Mailer X1.25) id 4888; Fri, 12 Feb 88 00:07:54 MST
Date: Thu, 11 Feb 88 22:43:14 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Bernard Chazelle <chazelle%Princeton.EDU@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Bernard Chazelle <chazelle%Princeton.EDU@forsythe.stanford.edu>
Subject: Princeton Forum on Algorithms and Complexity
To: Local Distribution <aflb.tn@sushi.stanford.edu>
-------------------------------------------------------------------------
PRINCETON FORUM ON ALGORITHMS AND COMPLEXITY
(March 1-2, 1988)
TUESDAY, March 1
Morning
9:00 Registration
9:45 Words of welcome
10:00 Amortized Analysis of Data Structures
Robert E. Tarjan, Princeton University
10:45 Coffee break
11:15 Near-Optimal Solutions to Very Large Traveling Salesman Problems
David S. Johnson, AT&T Bell Laboratories
12:15 Lunch, Fine Hall
Afternoon
2:00 The DNA Experiment
Richard J. Lipton, Princeton University
2:45 A Theory of Concentrators
Nicholas Pippenger, IBM Almaden
3:30 Coffee break
4:00 Recent Results in Machine Learning Theory
Ronald L. Rivest, Massachusetts Institute of Technology
6:00 Reception, Prospect House
WEDNESDAY, March 2
Morning
9:30 Towards Automating the Analysis of Algorithms
Philippe Flajolet, INRIA
10:15 Experimental Analysis of Algorithms
Jon L. Bentley, AT&T Bell Laboratories
11:00 Coffee break
11:30 Pat: a Tool for Searching the Oxford English Dictionary
Gaston H. Gonnet, University of Waterloo
12:15 Lunch, Nassau Inn
Afternoon
2:00 Discussion of Research Directions
2:30 Problem Session
All talks will take place in the Prince William Ballroom,
Nassau Inn, Princeton, NJ.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
There is a $50 registration fee ($25 for students)
to help defray the costs of lunches, coffee breaks,
and other social functions. Overnight accommodations
are available at the Nassau Inn and nearby hotels (see list below).
For reservations at the Inn, call (609) 921-7500 and ask for the
special rate.
If you are interested in attending the forum, please return the form
below along with the registration fee.
-------------------------------------------------------------------------
PRINCETON FORUM March 1-2, 1988
Name:
Address:
Tel: E-mail:
I enclose a check of $50 ($25 if student),
payable to "Princeton University"
Bernard Chazelle
Department of Computer Science
Princeton University
Princeton, NJ 08544
Phone: (609) 452-5380
CSNET: chazelle@princeton
-------------------------------------------------------------------------
NEARBY HOTELS
Nassau Inn - 921-7500 (or 800-843-6664)
Palmer Square
Peacock Inn - 924-1707
20 Bayard Lane
Holiday Inn - 452-9100 (or 800-HOLIDAY)
10 U.S. Route 1 at Plainsboro Road
Hyatt Regency - 987-1234 (or 800-228-9000)
Route 1 North at Alexander Road (in Carnegie Center)
McIntosh Inn - 896-3700
3270 Brunswick Pike
Lawrenceville, New Jersey (near Quaker Bridge Mall)
Marriott - 452-7900 (or 800-228-9290)
Route 1 and College Road West (at Princeton Forrestal Center)
Ramada Inn - 452-2400 (or 800-228-2828)
U. S. Route 1 and Ridge Road
Red Roof Inn#896-3388
3203 Brunswick Pike
Lawrenceville, New Jersey (adjoining Mercer Mall)
Scanticon - 452-7800 (or 800-327-7393)
100 College Road East (near Princeton Forrestal Center)
***** All hotels have airport shuttle stops (Princeton Airporter
and Salem Transportation shuttles) except the Peacock Inn
and the McIntosh Inn.
Princeton Airporter (connections to Newark) - 734-9200
Salem Transportation (connections to Newark and Kennedy - 924-3098
(or 882-7800)
∂12-Feb-88 0030 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talks
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 00:30:38 PST
Date: Thu 11 Feb 88 15:14:14-PST
From: Anil R. Gangolli <GANGOLLI@Sushi.Stanford.EDU>
Subject: Upcoming AFLB Talks
To: aflb.all@Sushi.Stanford.EDU
Office Phone: (415) 723-3605
Message-ID: <12373974900.48.GANGOLLI@Sushi.Stanford.EDU>
PLEASE NOTE:
* The Mar. 3 slot is still open. If you would like to speak,
please contact me (gangolli@sushi.stanford.edu).
THIS WEEK'S TALK:
18-February-1988: Herbert Wilf (Stanford)
Algorithms and Unique Representations
Several years ago I worked out a graph theoretical structure in which
a number of algorithms for sequencing members of combinatorial
families could be carried out. Yet another category of applications
of these structures has to do with unique representations of integers,
and in this talk I will discuss those theorems.
*** Time and Place: 12:30pm, Th, Feb. 18, Margaret Jacks Hall (MJH), Room 352
NEXT WEEK'S TALK:
25-February-1988: Lenore Blum (Mills College & UC Berkeley)
Computing over the Reals (or any Arbitrary Ring)
Classically, the theory of computation deals with discrete structures
(e.g., the integers or the rationals). Here, foundational issues
(such as what are appropriate models of computation and measures of
complexity) are well understood. One has confidence in a natural and
polynomially invariant theory.
This is far from the case in computing over continuous structures (such
as the reals). To point to a concrete case, the main competing algorithms
for the linear programming problem (e.g., Simplex and Karmakar's algorithm)
are defined and analyzed using incomparable models of computation
and measures of complexity.
I will discuss various issues involved (e.g., the role of the "condition"
of a problem), and a proposed model of computation over an arbitrary
ring R. In this general setting, we get universal machines, normal forms,
R.E. sets, as well as P, NP and NP complete classes. While our theory
reflects the classical over Z (e.g. the computable functions are the
recursive functions) it also reflects the special mathematical character
of the underlying ring R (e.g. complements of Julia sets provide examples
of R.E. undecidable sets over the reals) and provides a natural setting
for studying foundational issues concerning algorithms in numerical analysis.
This is joint work in progress with M. Shub and S. Smale.
*** Time and Place: 12:30pm, Th, Feb. 25, Margaret Jacks Hall (MJH), Room 352
-------
∂12-Feb-88 0216 @Score.Stanford.EDU:DURAN@Sushi.Stanford.EDU Students and Polya
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 02:16:46 PST
Received: from Sushi.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 12 Feb 88 02:09:00-PST
Date: Fri 12 Feb 88 02:08:24-PST
From: Raul Duran <DURAN@Sushi.Stanford.EDU>
Subject: Students and Polya
To: students@Score.Stanford.EDU, faculty@Score.Stanford.EDU
Message-ID: <12374093988.13.DURAN@Sushi.Stanford.EDU>
To CSD students, and interested faculty:
As you may know a general student meeting was held on Tues. Jan 26.
A good portion of the meeting centered on a heated discussion about the
department's actions with regards to POLYA, other similar actions (e.g.
the photocopying controversy), and the ramifications of such actions. As a
result, it was decided that we should write a letter to express
student dissatisfaction and to cause reconsideration of the "compelling"
Polya policy which was sent out by professor Nils Nilsson on Jan 23.
Let us begin by responding to some of the points made by professor Nilsson in
the proposal of Jan 23:
"I realize that some will feel that a POLYA policy based on these
ideas is not sufficiently generous, but both financial realities
and departmental traditions regarding research require it."
-- Nils Nilsson
Thus there are two basic points to consider:
* financial realities, and
* departmental traditions regarding research
Let us reiterate the counterproposal submitted by the students and supported
by several faculty (e.g. Cheriton):
"The students were unanimous in their belief that we should give all
students a Polya account. They understood the problem was that we
are concerned about how much the department will spend, but they felt
it was better to give everyone an account with a smaller limit rather
than not giving accounts to certain students."
-- gist of counterproposal by students
"I propose that all Ph.D. students be allotted the same dollar limit
per month and any student can get that upped by coming up with a sponsor"
-- Cheriton
Assuming a lower cost limit per student and raising the number students to
include all students should then have no effect on the total cost -- that
is, the counterproposal made by the students should not add additional
financial liability. Of course there are complications in that the pricing
policies for Polya are quite different than that of Sushi and are complicated
further by several legal issues. However, it should still be possible to
determine appropriate limits so that all students recieve accounts.
Note that the counterproposal is not at odds with the tradition of
research wherein a student enters into an "agreement" with a research
group and it then becomes the responsibility of the group to provide
facilitities for the student. In addition, the students' proposal is much
more in accordance with the "sushi tradition".
Let us briefly consider several other practical points which make the current
proposal unpalatable:
* The lack of computing resources discourages experimental and
independent research by students, especially those not currently
associated with a research group.
* Polya should serve as a central repository for departmental resources
and as such, everyone affiliated with the department should have some
form of access to Polya. At the meeting of the facilities committee
it was pointed out that certain facilities would only be available on
Polya.
* Some research groups do not have sufficient funding to purchase
Polya resources. Note that the policy proposed by professor Nilsson
distinguishes such groups -- there is a distinction between those groups
which have and those which have not.
* Students face the prospect that they will lose computing facilities if
they cannot find a research group to support their activities after the
first year. An important question to ponder is whether prospective
students will accept this "tradition" or policy.
* It was determined at the facilities committee meeting that
universal access might allow for better accounting of (for example)
printing costs.
* Is it justifiable to charge non-research computing (currently
provided by Sushi) to research accounts?
Up to this point the discussion has centered around the superficial issues
with regards to Polya. However, it is perhaps more important to consider the
deeper issues of the actions associated with Polya and how they are percieved
by the students and the outside world.
First of all, is it not a basic right of a student to recieve the materials
necessary to conduct his/her studies? We are COMPUTER SCIENTISTS
and THE BASIC TOOL OF THE COMPUTER SCIENTIST IS THE COMPUTER. Removing
computer access removes our fundamental research tool. If we do not accept
the notion that necessary materials are a basic right, then consider the
notion that the basic purpose of graduate school is to conduct research.
In this case, we note that the basic mechanism for research by a computer
scientist is the computer -- again, removing computer access removes our
fundamental research tool.
A second issue concerns the seemingly lack of consideration of the students
in the planning activities of the department. In evidence we might consider
the motivations which led to the purchase of Polya. If Polya was purchased in
order to reduce departmental costs, then said reductions should reduce (or at
least maintain) the financial liability of the students, that is, the reduced
costs should not require the students to incur further financial liability
(e.g., Professor Nilsson's proposal requires that students with fellowships
should purchase computer time with their endowment). If Polya was purchased
to provide better service, then students should be beneficiaries of the
improved service. In constrast, the current proposal by Professor Nilsson
seeks to eliminate service for several students.
A third issue concerns the sense of unity within the department. This is
a deeper sense than that alluded to by Professor Nilsson -- that of an
environment which supports the long-term goals of the entire department.
This includes the students, research groups, etc. In essence, policies and
traditions that place a premium on scarce resources result in a competitive
environment in which acquisition rather than achievement is the metric for
success. The acquisition for some comes at the loss for others -- this cannot
harbor a sense of unity.
A fourth issue involves the "shortsightedness" of the department. The
policy proposed by professor Nilsson causes students to consider research
groups that currently have sufficient funds. Moreover, the policy serves
to inhibit groups with a current lack of resources. These conditions would
stifle groups with minimum resources. In a discipline such as computer
science which is rapidly evolving, it is difficult to predict future trends,
and thus, in the long-term, it befits us to keep all (or most) avenues open.
The final and perhaps the most important points center around the perception of
the department as a result of the current situation and the ramifications of
this perception. At present, the general feeling is that the department has
minimal real concern for students, that our opinions (even though they are
solicited) have minimal effect, and that the main function of the department
is to secure it's financial stability -- to the exclusion of academic
responsibility. Of course, we are aware of the need for financial security,
but a concurrent goal should be academic excellence.
This perception is now becoming widespread. A current email letter from
UC Berkeley expresses the "amusement" of several UCB students to the
plight of Stanford students. It has also been determined that two students
have decided against Stanford due to this perception.
The ramifications of this perception cannot be underestimated. Any
research-oriented academic institution consists of two parts: the researchers
(its faculty) and their associates (the students). The actions of the
department in this matter have the effect of cutting the second arm of this
union -- the students.
The fact of the matter is that Stanford is not the only excellent institution
of higher learning. Faced with the above perception and the conditions
imposed by professor Nilsson's proposal, prospective students having alternatives and financial support (usually the best students) would do
better in considering those alternatives. Indeed, several students within
the department have expressed honest opinions that they can no longer
recommend the department to prospective students.
In closing, we request that the current proposal be reconsidered and
ask for support from students and faculty in this regard. If you feel
that such a request should be considered and would support a meeting
(or some other such medium) to develop a counterproposal, then send a
reply to duran@sushi. I will collect all the names and send the
statement:
"The enclosed letter was sent out to the CSD students and faculty to elicit
support to reconsider the propossal set forth by Professor Nilsson with
regards to Polya. We the undersigned believe that the proposal requires
further consideration and amendment. We support the formation of a group
of interested parties (students, faculty, and staff) to develop a
counterproposal which recognizes the need for financial stability and
academic excellence"
along with a copy of the letter above to Professor Nilsson.
-- Student bureacrats
-------
∂12-Feb-88 0832 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu INNS 88 UPDATE AND CALL FOR PAPERS
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 08:32:39 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Fri 12 Feb 88 08:26:07-PST
Received: by lindy.stanford.edu; Fri, 12 Feb 88 08:32:10 PST
Received: by Forsythe.Stanford.EDU; Fri, 12 Feb 88 08:30:20 PST
Received: by BYUADMIN (Mailer X1.25) id 8716; Fri, 12 Feb 88 09:23:43 MST
Date: Thu, 11 Feb 88 22:52:09 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Michael Cohen <mike%bucasb.bu.edu@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Michael Cohen <mike%bucasb.bu.edu@forsythe.stanford.edu>
Subject: INNS 88 UPDATE AND CALL FOR PAPERS
To: Local Distribution <aflb.tn@sushi.stanford.edu>
International Neural Network Society
First Annual Meeting
September 6--10, 1988
Boston, Massachusetts
The International Neural Network Society (INNS) invites all
those interested in the exciting and rapidly expanding field of
neural networks to attend its 1988 Annual Meeting. Incorporated
in 1987, INNS already includes among its members 1300 of the field's
most active researchers and is growing rapidly. The meeting
includes plenary lectures, symposia, contributed oral and poster
presentations, tutorials, commercial and publishing exhibits,
government agency presentations, and social events. These events will
bring together scientists, engineers, government administrators, industrial
administrators, and students in an open form for advancing the full
spectrum of significant neural network research from biology through
technology.
JOIN US IN BOSTON IN SEPTEMBER!
INNS OFFICERS AND GOVERNING BOARD:
Stephen Grossberg, President;
Demetri Psaltis, Vice-President;
Harold Szu, Secretary and Treasurer.
Shun-ichi Amari, James Anderson, Gail Carpenter, Walter Freeman, Kunihiko
Fukushima, Lee Giles, Teuvo Kohonen, Christoph von der Malsburg, Carver Mead,
David Rumelhart, Terrence Sejnowski, George Sperling, Bernard Widrow.
MEETING ORGANIZERS:
General Meeting Chairman: Bernard Widrow
Technical Program Co-Chairmen: Dana Anderson and James Anderson
Organization Chairman: Gail Carpenter
Tutorial Program Co-Chairmen: Walter Freeman and Harold Szu
Conference Coordinator: Maureen Caudill
Publications Coordinators: Charles Butler and Maureen Caudill
Publicity and Vendor Liaisons: Tom Schwartz and Diane Schwartz
COOPERATING SOCIETIES:
The Societies listed below have generously agreed to cooperate with the INNS
meeting. Organizing Committee for Cooperating Societies: Mark Kon
(Chairman), Joseph Bronzino, William Freeman, Morris Hirsch, William
Hutchinson, Simon Levin, Daniel Levine, Herbert Rauch, David Rumelhart, Jay
Sage, Bernard Soffer.
American Mathematical Society
Association for Behavior Analysis
Cognitive Science Society
Computer Society of the IEEE
IEEE Control Systems Society
IEEE Engineering in Medicine and Biology Society
IEEE Systems, Man and Cybernetics Society
Optical Society of America
Society for Industrial and Applied Mathematics
Society for Mathematical Biology
Society of Photo-Optical Instrumentation Engineers
Society for the Experimental Analysis of Behavior
-------------------------(cut here)-------------------------
---A DAY OF TUTORIALS---
September 6, 1988
8:00AM--6:00PM
1. JOHN DAUGMAN, Harvard University: Vision and image processing
2. TEUVO KOHONEN, Helsinki University of Technology: Speech and language
processing
3. STEPHEN GROSSBERG, Boston University: Sensory-motor control and robotics
4. GAIL CARPENTER, Northeastern University: Pattern recognition, associative
learning, and self-organization
5. DAVID RUMELHART, Stanford University: Cognitive psychology for information
processing
6. ALLEN SELVERSTON, University of California at San Diego: Local circuit
neurobiology
7. MORRIS HIRSCH, University of California at Berkeley: Nonlinear dynamics for
neural networks
8. DEMETRI PSALTIS, California Institute of Technology: Applications,
combinatorial optimization, and implementations
The tutorial registration fee includes all eight one-hour tutorial lectures by
leading scholars in each subject. A reception at 6:00PM will be followed by a
plenary lecture.
SYMPOSIUM AND PLENARY SPEAKERS:
Plenary Cognitive and Neural Systems
------- ----------------------------
Stephen Grossberg James Anderson
Carver Mead Walter Freeman
Terrence Sejnowski Guenter Gross
Nobuo Suga Gary Lynch
Bernard Widrow Christoph von der Malsburg
David Rumelhart
Allen Selverston
Vision and Pattern Recognition Combinatorial Optimization
------------------------------ and Content Addressable Memory
Gail Carpenter ------------------------------
Max Cynader Daniel Amit
John Daugman Stuart Geman
Kunihiko Fukushima Geoffrey Hinton
Teuvo Kohonen Bart Kosko
Ennio Mingolla
Eric Schwartz
George Sperling
Steven Zucker
Applications and Implementations Motor Control and Robotics
-------------------------------- --------------------------
Dana Anderson Jacob Barhen
Michael Buffa Daniel Bullock
Lee Giles James Houk
Robert Hecht-Nielsen Scott Kelso
Demetri Psaltis Lance Optican
Thomas Ryan
Bernard Soffer
Harold Szu
Wilfrid Veldkamp
-------------------------(cut here)-------------------------
---CONTRIBUTED ORAL AND POSTER PRESENTATIONS---
Submit abstracts for oral and poster presentation on biological and
technological models of:
Vision and image processing
Local circuit neurobiology
Speech and language
Analysis of network dynamics
Sensory-motor control and robotics
Combinatorial optimization
Pattern recognition
Electronic implementation (VLSI)
Associative learning
Optical implementation
Self-organization
Neurocomputers
Cognitive information processing
Applications
Abstracts must be typed in the INNS camera-ready format. Either printed
abstract forms or white bond paper may be used. Instructions for Authors
are attached. Submit completed abstracts to:
INNS Conference
16776 Bernardo Center Drive
Suite 110B
San Diego, CA 92128 USA
(619) 451-3752
ABSTRACT DEADLINE: MARCH 31, 1988
Acceptance notifications will be mailed in June, 1988. Accepted abstracts
will be published as a supplement to the INNS journal, Neural Networks,
and mailed to meeting registrants and Neural Networks subscribers in
August, 1988.
---PROGRAM COMMITTEE---
Joshua Alspector Walter Freeman Lance Optican
Shun-ichi Amari Kunihiko Fukushima David Parker
Dana Anderson Lee Giles Demetri Psaltis
James Anderson Stephen Grossberg Adam Reeves
Jacob Barhen Morris Hirsch Thomas Ryan
Michael Buffa Scott Kelso Jay Sage
Daniel Bullock Daniel Kersten Eric Schwartz
Marcia Bush Teuvo Kohonen Allen Selverston
Terry Caelli Bart Kosko George Sperling
Gail Carpenter Daniel Levine David Stork
Michael Cohen William Levy Harold Szu
Max Cynader Richard Lyon David Tank
John Daugman Carver Mead Wilfrid Veldkamp
David van Essen Ennio Mingolla William Warren
Federico Faggin Paul Mueller Bernard Widrow
Nabil Farhat Gregory Murphy
NSF TRAVEL GRANTS: The National Science Foundation has awarded a grant to
help students, postdoctoral fellows, and junior faculty travel to the INNS
Annual Meeting. Preference will be given to young scientists who are authors or
co-authors of contributed papers. A letter of request for travel support should
be sent along with the abstract. Please include the name, address, and
telephone number of each person requesting support; an estimate of basic travel
expenses; and the title and authors of the abstract. Awards will be announced
in June, 1988.
Complete attached forms for Conference and Tutorial Registration, Hotel
Reservations, and Discounted Travel Reservations. The celebrated Park Plaza
Castle will house many commercial, government, and publishing exhibits.
For exhibitor information write:
INNS Conference
J.R. Schuman Associates
316 Washington St.
Box 125
Wellesley, MA 02181 USA
(617) 237-7931.
-------------------------(cut here)-------------------------
---INSTRUCTIONS FOR AUTHORS OF ABSTRACTS---
International Neural Network Society
First Annual Meeting
September 6--10, 1988
Boston, Massachusetts
An abstract may be typed on white bond paper, as specified below.
Alternatively, a printed abstract form can be obtained by writing:
INNS Conference
16776 Bernardo Center Drive
Suite 110B
San Diego, CA 92128 USA
(619) 451-3752
STEPS TO FOLLOW:
Mail to: INNS Conference, 16776 Bernardo Center Drive, Suite 110B, San Diego,
CA 92128 USA. Include:
1. Original abstract, typed on INNS abstract form or on white bond legal size
(8-1/2" x 14") paper. DO NOT FOLD.
2. Five (5) photocopies.
3. Completed Abstract Information Form (next page).
4. A stamped, self-addressed acknowledgement card specifying abstract title
and authors (optional).
DEADLINE FOR SUBMISSION: Postmarked March 31, 1988
---ABSTRACT PREPARATION---
Abstract Style Guide (sample):
ADAPTIVE SWITCHING CIRCUITS. B. Widrow and M. Hoff. Department of Engineering,
Stanford University, Stanford, CA 94305 USA.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Style Rules:
Set title in CAPITAL LETTERS.
Underline authors' names.
Provide a full mailing address.
Skip one line following the address.
Indent paragraphs three spaces.
Single space.
Type right up to the margins. All text, including title, figures, and
references must fall within a 8-1/4-inch (width) x 11-inch (height)
rectangle.
Submitted abstracts will be reviewed by three members of the Program
Committee, and accepted abstracts will be published without revision. It is
therefore essential that abstracts be clear, specific, and self-contained.
Abstracts of previously published material should not be submitted. An
individual may appear as author on any number of abstracts. Acceptance
notifications will be mailed in June, 1988.
-------------------------(cut here)-------------------------
---ABSTRACT INFORMATION FORM---
International Neural Network Society
First Annual Meeting
September 6--10, 1988
Boston, Massachusetts
MAIL TO: INNS Conference, 16776 Bernardo Center Drive, Suite 110B, San
Diego, CA 92128 USA; (619) 451-3752
DEADLINE FOR RECEIPT OF ABSTRACTS: Postmarked by March 31, 1988.
1. Abstract title:
2. Presenting author:
3. Mailing address:
4. Telephone number(s):
5. Preferred presentation format: [ ] poster
[ ] oral (20 minutes)
6. Session number: First choice [ ]
Second choice [ ]
(1) Vision and image processing (8) Local circuit neurobiology
(2) Speech and language (9) Analysis of network dynamics
(3) Sensory-motor control and robotics (10) Combinatorial optimization
(4) Pattern recognition (11) Electronic implementation (VLSI)
(5) Associative learning (12) Optical implementation
(6) Self-organization (13) Neurocomputers
(7) Cognitive information processing (14) Applications
7. Projection equipment for oral presentations:
8. Signature (author):
9. Authorization (if needed):
Abstracts accepted for oral or poster presentation at the meeting will be
published in a supplement to the INNS official journal, Neural Networks.
Each camera-ready abstract will appear on a separate page. The supplement will
be mailed to meeting registrants and Neural Networks subscribers in
August, 1988, and will also be available at the meeting. It is thus
essential that Instructions for Authors and the deadline (March 31, 1988) be
strictly observed.
Submission of an abstract constitutes permission to have it published as a
supplement to Neural Networks.
-------------------------(cut here)-------------------------
---CONFERENCE AND TUTORIAL REGISTRATION FORM---
International Neural Network Society
First Annual Meeting
September 6--10, 1988
Boston, Massachusetts
Name:
Organization:
Address:
Telephone(s):
Conference Registration Fee Schedule: CIRCLE ONE:
September 6, 1988 (6 PM) -- September 10, 1988 (5 PM)
INNS Member Non-member
Until March 31, 1988 $125 $170 *
After March 31, 1988 $175 $220 *
Full-time student $50 $85 *
* Includes 1988 INNS membership; 1-year subscription to the INNS journal,
Neural Networks; and the Meeting Abstracts. A membership application form
is enclosed.
Tutorial Registration Fee Schedule: CIRCLE ONE:
Tuesday, September 6, 1988 (8 AM -- 6 PM)
Note: Tutorial attendees must also register for the conference
INNS INNS
Regular Member Student Member
Until March 31, 1988 $100 $30
After March 31, 1988 $150 $60
Tutorial registration fees do not include the price of tutorial lecture notes.
Cancellation Policy: Conference and tutorial fees, less $30, will be
refunded upon receipt of a written request dated before July 31, 1988.
After that date, no refund will be made.
Check or money order for $___ enclosed.
Payable to: INNS.
Or charge: ( ) MasterCard
( ) VISA
Account No.
Expiration Date
Signature
MAIL TO: J.R. Schuman Associates
Neural Networks 1988
P.O. Box 125
Wellesley, MA 02181
(617) 237-7931
-------------------------(cut here)-------------------------
---HOTEL RESERVATION FORM---
International Neural Network Society
First Annual Meeting
September 6--10, 1988
Boston, Massachusetts
Room Reservation: Boston Park Plaza Hotel
One Park Plaza at Arlington
Boston, MA 02117 USA
Name:
Address:
Nunber in Room:
City:
State:
Country:
Postal/Zip Code:
Arrival Date:
Departure Date:
Ref: Neural Networks
$91 (+ tax)/night, single or double. Conference rate applies for
arrivals on (or after) September 3, 1988, and for departures on
(or before) September 11, 1988.
Reservations for arrival after 4 PM must be guaranteed by:
( ) Check ($91 enclosed)
Or credit card: ( ) VISA
( ) American Express
Card No.
Expiration Date
Signature
The INNS room block at the Boston Park Plaza Hotel will be saved until
August 5, 1988. After that date reservations will be made on a space-available
basis.
If plans change or you need to cancel (before 4 PM Boston time) call
(800) 225-2008 to avoid billing, and retain cancellation number given
by hotel agent.
Reservations will be made at a nearby hotel if the Boston Park Plaza Hotel
no longer has rooms available.
Check in after 2 PM --- Check out prior to 1 PM.
MAIL TO:
The Boston Park Plaza Hotel
Attn: Reservations Manager
50 Park Plaza
Boston, MA 02117 USA
Telex 940107
(800) 225-2008 (Continental US)
(800) 462-2022 (Massachusetts only)
-------------------------(cut here)-------------------------
---INTERNATIONAL NEURAL NETWORK SOCIETY---
MEMBERSHIP APPLICATION FORM
The International Neural Network Society (INNS) is an association of
scientists, engineers, students, and others seeking to learn about and
advance our understanding of the modelling of behavioral and brain processes,
and the application of neural modelling concepts to technological problems. The
INNS will sponsor its first annual international meeting in Boston,
Massachusetts, September 6-10, 1988. INNS membership includes a subscription
to Neural Networks, the official journal of the Society, and the Annual
Meeting Abstracts.
Membership Fees 1987--88 (including a 1-year subscription to Neural Networks)
( ) Regular ($45)
( ) Full-time Student ($35)
Check or money order for $___ enclosed (payable to INNS)
Or Charge: ( ) MasterCard
( ) VISA
[Bill will read: "Pergamon Press", the publisher of Neural Networks]
Account Number
Expires
Signature
Name
Title
Department
Institution
Employment: ( ) University
( ) Government
( ) Industry
( ) Other
Mailing Address
Electronic Mail Address
Telephone(s)
Education: Highest Degree
Date
University
Department
Check your principal areas of interest in neural networks:
( ) Vision and image processing
( ) Local circuit and systems analyses of brain-behavior relationships
( ) Speech and language understanding
( ) Pattern recognition
( ) Combinatorial optimization
( ) Associative learning and long-term memory
( ) Electronic hardware
( ) Optical hardware
( ) Self-organization
( ) Hybrid hardware
( ) Cognitive information processing
( ) Virtual devices
( ) Cooperative and competitive network dynamics and short-term memory
( ) Neurocomputers
( ) Sensory-motor control and robotics
( ) Parallel distributed processing
( ) Other
Signature
Date
Mail to: Dr. Harold Szu
NRL, Code 5756
Washington, DC 20375-5000
(202) 767-1493
E-Mail: ARPNET-Szu@NRL3
-------------------------(cut here)-------------------------
---CALL FOR PAPERS---
Neural Networks commenced quarterly publication in January, 1988.
Articles span the full range of biological through technological neural
network models. The January issue includes:
Teuvo Kohonen: An introduction to neural computing.
Stephen Grossberg: Nonlinear neural networks: Principles, mechanisms,
and architectures.
Shun-ichi Amari and Kenjiro Maginu: Statistical neurodynamics of associative
memory.
Paul R. Gorman and Terrence J. Sejnowski: Analysis of hidden units in a
layered network trained to classify sonar targets.
Carver A. Mead and Misha Mahowald: A silicon model of early visual
processing.
The April, 1988, issue will include:
Allen Selverston: A consideration of invertebrate central pattern generators as
computational data bases.
Kunihiko Fukushima: Neocognitron: A hierarchical neural network capable of
visual pattern recognition.
Robert Hecht-Nielsen: Applications of counterpropagation networks.
Christoph von der Malsburg: Pattern recognition by labeled graph matching.
Demetri Psaltis, Cheol Hoon Park, and John Hong: Higher order associative
memories and their optical implementations.
INSTRUCTIONS FOR AUTHORS:
Authors should submit four copies of each manuscript, plus original
illustrations. Do references in American Psychological Association
format; e.g., Hebb (1949). Submit from Asia and Australia to Prof. Shun-ichi
Amari; from North and South America to Prof. Stephen Grossberg; from Europe
and Africa to Prof. Teuvo Kohonen. Complete Instructions for Authors
may be obtained from the Editors.
-------------------------(cut here)-------------------------
---DISCOUNTED TRAVEL RESERVATIONS---
International Neural Network Society
First Annual Meeting
September 6--10, 1988
Boston, Massachusetts
Domestic Travelers: Airline tickets may be ordered at a special convention
rate 60% off coach fares on Eastern Airlines and 5% off the lowest available
fare on Continental Airlines. Eastern and Continental airlines have the
greatest number of flights in and out of Logan International Airport in
Boston. Convention rates are often the lowest unrestricted rates obtainable at
the time you book your flights. However, since the rate is negotiated far in
advance, and since the airlines may offer special lower fares at the time you
book, especially if you are willing to stay over a Saturday night, there may be
even lower fares available than our convention rate. However, if you book your
flight through UNIGLOBE The Travel Connection, Inc., we guarantee to find you
the lowest available fare at the time of booking, whether that is the
convention fare or a lower fare on another airline, or we will refund the
difference between our fare and the lower one.
International Travelers: Because of the weakness of the U.S. dollar, it may be
less expensive to purchase your ticket through us in the United States. You
may call us collect on our local (617) telephone line, let us know what the
lowest fare is you have been quoted in your country, and we will obtain a lower
one in U.S. currency if possible.
Call UNIGLOBE The Travel Connection Inc.: (800) 521-5144 (outside
Massachusetts) or (617) 235-7500 (Massachusetts and International), or fill out
the Travel Request below and send to:
Neural Networks
UNIGLOBE The Travel Connection, Inc.
40 Washington Street
Wellesley, MA 02181
Name:
Address:
City, State, Zip:
Telephone (Work and Home):
Departure from (City/Airport):
Date and Preferred Time:
Date and Preferred Time:
Form of Payment:
We will call you to confirm reservations and obtain seat assignment
preferences, frequent flier numbers, or any other special request
you may have.
∂12-Feb-88 0906 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu leaving Stanford
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 09:06:07 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 12 Feb 88 08:56:13-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA03889; Fri, 12 Feb 88 09:01:18 PST
Date: Fri, 12 Feb 88 09:01:18 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8802121701.AA03889@Tenaya.stanford.edu>
To: REGES@Score.stanford.edu
Cc: csd-list@Score.stanford.edu
In-Reply-To: Stuart Reges's message of Thu 11 Feb 88 20:22:47-PST <12374031069.15.REGES@Score.Stanford.EDU>
Subject: leaving Stanford
I want to wish Stuart Reges the best of luck in his new job and thank
him on behalf of all of us at Stanford for an absolutely superb six
years here. We wouldn't have achieved most of what we have done in
education, televised courses, and administrative computing without
Stuart. He has been a phenomenon who has been just plain exciting to
watch!
Is there life after Stuart? I am meeting with interested faculty and
am scheduling meetings with the lecturers to discuss this very topic.
I think we'll come up with some ideas. First, we are putting together
a search committee to conduct a nation-wide search for a new
Asst. Chair for Education. George Wheaton is coordinating the meetings
of this committee and has "volunteered" to be the central point to
receive suggestions about possible candidates. I am very proud of what
Stuart and our lecturers have achieved in putting together first-rate
courses and cs major programs. We can stay strong only by continuing
to work together now to plan for the future. I'll be anxious to
hear suggestions.
-Nils
∂12-Feb-88 0921 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Students and Polya
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 09:20:31 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 12 Feb 88 09:06:45-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA03911; Fri, 12 Feb 88 09:11:42 PST
Date: Fri, 12 Feb 88 09:11:42 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8802121711.AA03911@Tenaya.stanford.edu>
To: DURAN@Sushi.stanford.edu
Cc: students@Score.stanford.edu, faculty@Score.stanford.edu
In-Reply-To: Raul Duran's message of Fri 12 Feb 88 02:08:24-PST <12374093988.13.DURAN@Sushi.Stanford.EDU>
Subject: Students and Polya
Thanks, Raul, for your thoughtful note. I'll read it carefully in
detail and hope to respond next week. As it flashed by, I did notice
some points that really should be discussed in person. Perhaps the
bureaucrats could arrange a meeting with some students and me (and one
or two interested faculty---such as Cheriton and maybe a "theory"
faculty member).
-Nils
∂12-Feb-88 0958 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Computing and Polya
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 09:58:01 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 12 Feb 88 09:42:55-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA03997; Fri, 12 Feb 88 09:48:02 PST
Date: Fri, 12 Feb 88 09:48:02 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8802121748.AA03997@Tenaya.stanford.edu>
To: faculty@score
Subject: Computing and Polya
The following correspondence between me and Vaughan Pratt helps
illuminate my position regarding "free" student computing. It
should be read in the context of Raul Duran's recent msg concerning
student computing. -Nils
-----
Return-Path: <@Score.stanford.edu:coraki!pratt@Sun.COM>
Date: Fri, 12 Feb 88 07:25:46 PST
From: coraki!pratt@Sun.COM (Vaughan Pratt)
To: nilsson@score.stanford.edu
Subject: students
I've been unable to pay attention to the polya thing. However when
I was a student I had the same expectations of the department that
are being expressed by our students. I feel their position is valid.
-v
---
Return-Path: <nilsson@Tenaya.stanford.edu>
Date: Fri, 12 Feb 88 09:13:59 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
To: coraki!pratt@Sun.COM
In-Reply-To: Vaughan Pratt's message of Fri, 12 Feb 88 07:25:46 PST <8802121525.AA09436@>
Subject: students
Departments that provide free computing on a scale expected (and
deserved!) by our students charge the cost of such computing to
research projects. I'd be delighted to work with the PI's to
figure out how this can be done at Stanford.
∂12-Feb-88 1022 @Score.Stanford.EDU:jwilson@polya Students and Polya
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 10:21:58 PST
Received: from polya by SCORE.STANFORD.EDU with TCP; Fri 12 Feb 88 10:08:24-PST
Received: by polya (5.54/inc-1.2)
id AA29166; Fri, 12 Feb 88 10:13:22 PST
Date: Fri, 12 Feb 88 10:13:22 PST
From: jwilson@polya.stanford.edu (James Wilson)
Message-Id: <8802121813.AA29166@polya>
To: students@score.stanford.edu, faculty@score.stanford.edu
Subject: Students and Polya
I have a few comments to make about Raul's message.
> Is it justifiable to charge non-research computing (currently
> provided by Sushi) to research accounts?
Is it justifiable to charge it to the department? What do you define
as non-research computing? If you are talking about academic
coursework, sending/receiving e-mail, and playing games, Portia is
available for use.
A majority of the use of Sushi and Rocky is for e-mail/bboards/net news.
All you have to do is run "finger" to see this.
I think it is a joke that the login messages say these machines are
for "coursework and unsponsored research". Let's be honest! Sushi
served a need when LOTS TOPS-20 machines were overloaded, but now
academic computing can be done at LOTS. Unsponsored research? What
sort of research goes on? The only thing that I see resembling
research are papers written in scribe or latex.
James
∂12-Feb-88 1147 BERGMAN@Score.Stanford.EDU Spring quarter RAships
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 11:47:53 PST
Date: Fri 12 Feb 88 11:41:28-PST
From: Sharon Bergman <BERGMAN@Score.Stanford.EDU>
Subject: Spring quarter RAships
To: faculty@Score.Stanford.EDU
Message-ID: <12374198312.19.BERGMAN@Score.Stanford.EDU>
If there are any changes in support for your research assistants for
Spring Quarter, please let me know so that I can process the paperwork.
I need to be informed of any research assistants whose appointments
should be terminated as of March 31 and any new RA appointments beginning
Spring Quarter. (I will need the name, source of support, and percentage of
time.) If you want to change the source of support on any of your current
research assistants, let me know this also.
To be sure the student receives a bill with the correct tuition applied, the
RA paperwork should reach Graduate Awards by Feb. 19; therefore, please try
to get any information to me before this date if at all possible. (Also,
if you have decided on RA's for Summer Quarter at this early date, I would
appreciate this information.) Thank you.
-Sharon Bergman
-------
∂12-Feb-88 1227 @Score.Stanford.EDU:TEICH@Sushi.Stanford.EDU Re: Students and Polya
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 12:27:26 PST
Received: from Sushi.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 12 Feb 88 12:20:32-PST
Date: Fri 12 Feb 88 12:20:24-PST
From: David Teich <TEICH@Sushi.Stanford.EDU>
Subject: Re: Students and Polya
To: jwilson@polya.Stanford.EDU
cc: students@Score.Stanford.EDU, faculty@Score.Stanford.EDU
In-Reply-To: <8802121813.AA29166@polya>
Message-ID: <12374205398.41.TEICH@Sushi.Stanford.EDU>
James, are you aware that portia now has disk allocations set up? Are
you also aware that, by next year, they hope to have console allocations
set up? At that point, portia will have all the restrications of the rest
of the appropriately named tragedies.
david
-------
∂12-Feb-88 1533 @Score.Stanford.EDU:CREW@Sushi.Stanford.EDU Re: Students and Polya
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 15:33:28 PST
Received: from Sushi.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 12 Feb 88 15:17:23-PST
Date: Fri 12 Feb 88 15:09:45-PST
From: Roger Crew <Crew@Sushi.Stanford.EDU>
Subject: Re: Students and Polya
To: faculty@Score.Stanford.EDU, students@Score.Stanford.EDU
Reply-To: csd@sushi.stanford.edu
Message-ID: <12374236229.17.CREW@Sushi.Stanford.EDU>
can we PLEASE keep this discussion on the CSD bboard ...?
Roger
(cf. my message on SU-COMPUTERS about the use of large volume mailing lists)
-------
∂12-Feb-88 1720 @Score.Stanford.EDU:jlh@vsop.stanford.edu visit of Faculty candidates
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 17:20:21 PST
Received: from vsop.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 12 Feb 88 17:14:20-PST
Received: by vsop.stanford.edu; Fri, 12 Feb 88 17:16:34 PST
Date: 12 Feb 1988 1716-PST (Friday)
From: John Hennessy <jlh@vsop.stanford.edu>
To: faculty@score.stanford.edu, csl-faculty@sierra.stanford.edu
Cc: margaret@vsop.stanford.edu
Subject: visit of Faculty candidates
Our first two faculty candidates are coming through next week. Jennifer
Widom will be visiting Thursday, she works on formalisms for
distributed and concurrent programming. She will speak Thursday at 9:30
in MJH, Room 352. Her talk is titled: "Trace-Based Network Proof
Systems: Expressiveness and Completeness."
Alex Aiken will visit on Friday. He works in the area of program
transformations for parallelism. He will talk on: "Compaction-Based
Parallelization," on Friday 10:00 a.m., also in Room 352, MJH.
Both Alex (just finishing) and Jennifer (acting asst prof.) are from
Cornell. Please attend the seminars if possible. If you would like to
talk to the candidates individually, arrange an appointment with my
secretary Margaret (margaret@mojave).
∂13-Feb-88 1242 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Accounts on Polya
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Feb 88 12:42:20 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sat 13 Feb 88 12:36:16-PST
Date: 13 Feb 88 1241 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Accounts on Polya
To: faculty@SCORE.Stanford.EDU, CSD@SAIL.Stanford.EDU
This is going to be a longish message, but it will contain a lot of
information. I will first discuss what I consider to be reasonable set of
goals. Then I will mention the realities and the various proposals
around. Lastly, I will propose an alternative approach.
Goals and Issues
1. Everyone affiliated with CSD should have sufficient resources to do
all the computing relevant to that affiliation with CSD. This includes
sponsored and unsponsored research computing, coursework, electronic mail,
bboards, and others.
2. There are a variety of machines on which this computing can take
place. These include shared CSD-CF administered computers like Score and
Polya, research project computers like LISP machines and some SUNs,
University sponsored resources like AIR and LOTS, and department-provided
resources like Sushi.
3. The department needs to avoid spending unlimited amounts of money on
unsponsored computing. It can provide a limited, fixed budget for these
purposes, however.
4. Faculty want to provide for the general good of the department, but
can do so in limited ways, as a result of budgetary and time
considerations.
Realities and Comments on Current Proposals
Fixed dollar limits for dept.-sponsored accounts on Polya will not
directly affect the deep pocket problem of the department. The dollar
amounts would be set based on statistical usage patterns, since not
everyone would use their entire allocation.
Fixed dollar limits might mean some student could not access Polya after,
say, the 20th of the month because of exceeding the limit.
Computer Forum funds are currently paying for TAships and for Sushi to a
large extent. Additional funding comes from TV classes and Honors Co-op.
The University does not provide sufficient funding for TAs and does not
provide any funding for Sushi.
PIs should not be taxed unduly because they are raising money for
sponsored research. No PI should be required to pay for any Polya account
merely because the PI is supporting that student. This is especially true
if the PI is already providing considerable computing resources on other
equipment.
The Computer Forum is available for all faculty members to participate in,
regardless of whether they have research funding. Some faculty members
would rather their financial obligations for the general good be satisfied
by service for the Forum rather than through other means. Those who are
doing yeoman service through the Forum and through supporting students
through sponsored research should not also be faced with providing
additional funds through accounts on Polya.
The University should be strongly pressured to provide unlimited computing
resources on AIR/LOTS. The placement of space quotas on Portia are not
unreasonable, but console allocation should be phased out on all AIR/LOTS
computers. Computers should be considered a resource like the library:
whoever suggests that library time should be rationed.
My Proposal
Let us suppose that the Polya costs $P per year. Let us suppose that
Sushi costs $S per year, or that the department is otherwise willing to
pay $S for unsponsored computing. Then the department should purchase
$S/$P fraction of Polya for unsponsored computing.
Disk space can easily be apportioned by creating a special partition for
this fraction for "Sushi" users. In addition, while the UNIX scheduler
does not allow for pie-sliced scheduling, a higher level process that
dynamically alters priorities based on usage patterns and pie-slice
allocations can approximate the amount purchased. The windfall (unused
slice of the pie) should be allocated, however.
Any project sufficiently large should be allowed to purchase a fraction of
Polya. A good minimum fraction is 10%. All other users would be charged
based on the standard usage accounting currently contemplated, but based
on ($P-$S) costs for ($P-$S)/$P fraction of the machine. Note that such
fixed charges will reduce the volatility of Polya income, although it will
increase the volatility of Polya rates for usage accounting.
The "Sushi" fraction of Polya could be allocated the same way Sushi is
currently, although we might want to prohibit people from have both
Sushi-like Polya accounts as well as usage-charged Polya accounts.
Comments
This is a serious proposal. Comments are solicited. In particular, I
would like to know more about the actual costs of Polya and how much the
dept *is* willing to spend on unsponsored computing.
Arthur
∂13-Feb-88 1415 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Help explain the concepts of the future
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Feb 88 14:15:41 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Sat 13 Feb 88 14:09:31-PST
Received: by lindy.stanford.edu; Sat, 13 Feb 88 14:15:44 PST
Received: by Forsythe.Stanford.EDU; Sat, 13 Feb 88 14:13:52 PST
Received: by BYUADMIN (Mailer X1.25) id 1355; Sat, 13 Feb 88 15:13:46 MST
Date: Sat, 13 Feb 88 11:13:58 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
G B Reilly <reilly%UDEL.EDU@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: G B Reilly <reilly%UDEL.EDU@forsythe.stanford.edu>
Subject: Help explain the concepts of the future
To: Local Distribution <aflb.tn@sushi.stanford.edu>
The Franklin Institute Science Museum* will be opening
the Futures Center in 1990. This is not a copy of EPCOT
Center or a futuristic living room. It is exhibits to
explain the new concepts in science and technology that will
affect people's lives in the coming years.
One section explains the concepts of robotics, computing,
and artificial intelligence. We are interested in hearing
what you believe the public needs to know about these areas
and how they will affect their life in the next decade.
Thank you for your cooperation.
Brendan Reilly
Curator
----
* The Franklin Institute is one of the oldest science museums
in the country and has hands-on exhibits explaining science
and technology which are visited by over one million people annually.
∂13-Feb-88 1439 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Boston University Graduate Program
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Feb 88 14:38:56 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Sat 13 Feb 88 14:32:47-PST
Received: by lindy.stanford.edu; Sat, 13 Feb 88 14:39:06 PST
Received: by Forsythe.Stanford.EDU; Sat, 13 Feb 88 14:37:36 PST
Received: by BYUADMIN (Mailer X1.25) id 1747; Sat, 13 Feb 88 15:35:59 MST
Date: Sat, 13 Feb 88 11:29:32 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Michael Cohen <mike%bucasb.bu.edu@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Michael Cohen <mike%bucasb.bu.edu@forsythe.stanford.edu>
Subject: Boston University Graduate Program
To: Local Distribution <aflb.tn@sushi.stanford.edu>
BOSTON UNIVERSITY
M.A. AND PH.D. PROGRAM IN COGNITIVE AND NEURAL SYSTEMS
Boston University will offer an M.A. and Ph.D. program in
Cognitive and Neural Systems starting in September, 1988,
pending final approval. This program will present an integrated
curriculum offering the full range of psychological, neurobiological,
and computational concepts, models, and methods in the broad field
variously called neural networks, connectionism, parallel distributed
processing, and biological information processing, in which Boston
University is an acknowledged leader. Each student will also be required
to take an equal number of carefully selected courses in one or more core
departments, such as psychology, biology, computer science, mathematics,
or engineering. A limited number of full-time graduate research fellowships
are expected to be available. For application materials, write
Prof. Stephen Grossberg, Chairman
CNS Program
Center for Adaptive Systems
Boston University
111 Cummington Street
Boston, MA 02215 USA
For further information, call (617) 353-7857 and ask for CNS information.
∂13-Feb-88 1656 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for Papers, FSTTCS '88
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Feb 88 16:56:26 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Sat 13 Feb 88 16:50:27-PST
Received: by lindy.stanford.edu; Sat, 13 Feb 88 16:56:45 PST
Received: by Forsythe.Stanford.EDU; Sat, 13 Feb 88 16:55:15 PST
Received: by BYUADMIN (Mailer X1.25) id 3110; Sat, 13 Feb 88 17:54:34 MST
Date: Sat, 13 Feb 88 16:23:35 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Ashok Chandra <ashok@ibm.com>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Ashok Chandra <ashok@ibm.com>
Subject: Call for Papers, FSTTCS '88
To: Local Distribution <aflb.tn@sushi.stanford.edu>
-------------------------------------------------------------------------
CALL FOR PAPERS
Eighth Conference on
Foundations of Software Technology and Theoretical Computer Science
Pune, India, 14-16 December 1988
Sponsored by:
Tata Institute of Fundamental Research
Tata Research Development and Design Centre
This annual conference is organized to provide a forum for presenting
original research results, from India and abroad, in theoretical aspects
of computer science and its application to software technology. Authors
are invited to submit papers in the following and related areas:
Programming and Proof Methodologies
Functional and Logic Programming
Formal Semantics and Specifications
Theory of Computation
Formal Languages and Automata
Algorithms and Complexity
VLSI
Database Theory
Distributed Computing
Software Technology
Papers should be at most 20 PAGES (5000 WORDS) long. The covering letter
should indicate the address (and author, in case of multiple authors) for
all further correspondence. The names of the authors and their
affiliations should only appear on the cover page of the paper. It should
be possible to remove this page and send the papers to reviewers to
facilitate blind refereeing. Please also give the CR classification
numbers on the cover page. When citing papers submitted elsewhere, but
not published at the time of submission to this conference, the
similarities, and more importantly the differences between such works
must be clearly brought out. FOUR copies of each paper should
be sent to:
K. V. Nori
FST & TCS 8
TRDDC
1, Mangaldas Road
Pune 411 001, INDIA
Tel: (212)-61608 Telex: 0145-464
to reach by MAY 16, 1988. Papers will be refereed and final selection
will be made by the Programme Committee. Authors will be informed of
acceptance by AUGUST 1, 1988 and final camera ready manuscript must be
received by SEPTEMBER 5, 1988 to be included in the proceedings.
Please see volumes 181, 206, 241 and 287 of Lecture Notes in Computer
Science series published by Springer Verlag, for the proceedings of
the past 4 FST & TCS Conferences.
CONFERENCE ADVISORY COMMITTEE
D. Bjorner (Denmark)
A. Chandra (IBM Res.)
B. Chandrasekaran (Ohio State)
S. Crespi Reghizzi (Milan)
Z. Galil (Columbia)
D. Gries (Cornell)
M. Joseph (Warwick)
A. Joshi (Pennsylvania)
U. Montanari (Pisa)
A. Nakamura (Hiroshima)
M. Nivat (Paris)
R. Parikh (New York)
S. Rao Kosaraju (Johns Hopkins)
S. Sahni (Minnesota)
W. A. Wulf (Tartan Labs.)
PROGRAMME COMMITTEE
A. Bagchi (IIM, Calcutta)
C. R. Muthukrishnan (IIT, Madras)
K. V. Nori (TRDDC, Pune)
L. M. Patnaik (IISc, Banglore)
H. V. Sahasrabuddhe (Pune University)
R. Sangal (IIT, Kanpur)
R. Siromoney (Madras Christian College)
C. E. Veni Madhavan (IISc, Banglore)
PUNE is a historical city about 150 kms. south east of Bombay.
It is well connected by air and train to all important cities
in India. December is a pleasant month in Pune, with temperatures
ranging from 8 degrees C at night to 25 degrees C in the afternoon.
It is a good time for sightseeing with the possibilities ranging from
hill stations and coastal resorts, to cave paintings, rock cut
temples and hill top forts.
∂13-Feb-88 1728 X3J13-mailer Issues from the cleanup sub-committee
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 17:28:50 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 17:29:36 PST
Date: 13 Feb 88 17:29 PST
From: Masinter.pa@Xerox.COM
Subject: Issues from the cleanup sub-committee
To: X3J13@Sail.stanford.edu
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880213-172936-10523@Xerox>
The cleanup committee has a number of issues for discussion and/or voting at the
next X3J13 meeting. I will be mailing out those issues which are ready for
voting at the next meeting, one at a time.
I am uncertain as to the exact procedure for voting; I imagine that Bob Mathis
will help clarify. My current understanding is that you should be prepared
either to vote for endorsing a proposal or should prepare a written objection.
Please address your replies directly to cl-cleanup@Sail.stanford.edu. We promise
to summarize and redistribute any replies we get. X3J13@Sail.stanford.edu should
*not* be used for technical discussions, however.
The cleanup issues fall into several categories.
Passed X3J13/Jun87:
Mailed to X3J13 prior to the June 1987 meeting of X3J13 and passed (via voice
vote) at that meeting.
As these were distributed before, they will not be mailed again except by
individual request, although the issues will appear on the ballot.
Conditionally passed X3J13/Jun87, new version passed X3J13/Nov87:
While an earlier version was mailed to X3J13 prior to the Jun87 meeting, the
most recent version was distributed only in hardcopy at the November 1987
meeting.
Passed X3J13/Nov87:
Distributed only via hardcopy at the November 1987 meeting.
New ballot items for Mar88:
Not previously distributed to X3J13, but ready for voting.
In discussion:
Some of these issues may be distributed via electronic mail to X3J13 prior to
the March meeting for discussion at the meeting, although they will not appear
on a ballot at that time.
∂14-Feb-88 1045 X3J13-mailer Issue ADJUST-ARRAY-DISPLACEMENT (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 10:45:27 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 10:45:59 PST
Date: 14 Feb 88 10:45 PST
From: Masinter.pa@Xerox.COM
Subject: Issue ADJUST-ARRAY-DISPLACEMENT (Version 4)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-104559-1224@Xerox>
This issue has not been distributed to X3J13 before.
!
Issue: ADJUST-ARRAY-DISPLACEMENT
Reference: ADJUST-ARRAY (CLtL p.297)
Category: Clarification
Edit history: Version 1 by Fahlman, 18-Apr-87 (from Steele's list)
Version 2 by Masinter
Version 3 by Masinter, 5-Jun-87 (respond to comments)
Version 4 by Masinter, 23-Nov-87
Problem Description:
The interaction of ADJUST-ARRAY and displaced arrays is insufficiently specified
in the case where the array being adjusted is displaced.
Proposal: ADJUST-ARRAY-DISPLAYCEMENT:RULES
Interaction of adjusting and displacement:
Suppose we are adjusting array A, which is perhaps displaced to B before the
ADJUST-ARRAY call and perhaps to C after the call.
(1) A is not displaced before or after: The dimensions of A are altered, and the
contents rearranged as appropriate. Additional elements of A are taken from the
:INITIAL-ELEMENT. The use of :INITIAL-CONTENTS causes all old contents to be
discarded.
(2) A is not displaced before, but is displaced to C after. As specified in
CLtL, none of the original contents of A appears in A afterwards; A now contains
the contents of C, without any rearrangement of C.
(3) A is displaced to B before the call, and is displaced to C after the call.
(B and C may be the same.) As in case (2), the contents of B do not appear in A
afterward (unless such contents also happen to be in C). If
:DISPLACED-INDEX-OFFSET is not specified in the ADJUST-ARRAY call, it defaults
to zero; the old offset (into B) is not retained.
(4) A is displaced to B before the call, but not displaced afterward. A gets a
new "data region", and contents of B are copied into it as appropriate to
maintain the existing old contents; additional elements of A are taken from the
:INITIAL-ELEMENT. However, the use of :INITIAL-CONTENTS causes all old contents
to be discarded.
If array X is displaced to array Y, and array Y is displaced to array Z, and
array Y is altered by ADJUST-ARRAY, array X must now refer to the adjusted
contents of Y. This means that an implementation may not collapse the chain to
make X refer to Z directly and forget that the chain of reference passes through
array Y. (Cacheing techniques are of course permitted, as long as they preserve
the semantics specified here and in CLtL.)
If X is displaced to Y, it is an error to adjust Y in such a way that it no
longer has enough elements to satisfy X. This error may be signalled at the
time of the adjustment, but this is not required.
Note: Omitting the :DISPLACED-TO argument to ADJUST-ARRAY is equivalent to
specifying :DISPLACED-TO NIL; in either case, the array is not displaced after
the call and case (1) or (4) hold.
Rationale:
This interaction must be clarified. This set of rules was proposed some time
ago, as a result of discussions on the Common Lisp mailing list, and this model
has been adopted by many Common Lisp implementations.
Current Practice:
Many implementations currently follow the model proposed here, although they
differ in some detail. For example, Symbolics Common Lisp behaves as indicated
except for case (4); in that case, it never copies the contents of B, and all
elements are taken from the :INITIAL-ELEMENT.
Cost to implementors:
Some existing implementations may have to be changed, but adopting any other
model would be worse. Public-domain code implementing this model is available
from CMU.
Cost to users:
This is a relatively uncommon situation, which is the reason it didn't occur to
the original language designers to specify how it works. Any user code that
cares about this issue probably already follows the proposed model.
Benefits:
Clarification of a situation that is currently not addressed by the standard.
Discussion:
The cleanup committee supports this clarification.
Some consideration was given to adding DISPLACED-ARRAY-P or ARRAY-DISPLACED-TO
and ARRAY-DISPLACED-INDEX-OFFSET which would allow access to information as to
whether an array was or was not displaced. However, these are not part of the
current proposal.
A similar issue arises with ADJUST-ARRAY and fill pointers, and will be the
subject of a separate issue.
∂14-Feb-88 1049 X3J13-mailer Issue: APPEND-DOTTED (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 10:49:35 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 10:50:04 PST
Date: 14 Feb 88 10:49 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: APPEND-DOTTED (Version 5)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-105004-1227@Xerox>
This issue was distributed in hardcopy at the November 1987 meeting of X3J13.
!
Issue: APPEND-DOTTED
References: APPEND (p268)
Category: CHANGE/CLARIFICATION
Edit history: 27-Jul-87, Version 1 by Pitman
29-Oct-87, Version 2 by Pitman (loose ends)
14-Nov-87, Version 3 by Masinter
23-Nov-87, Version 4 by Masinter
14-Jan-88, Version 5 by Masinter
Problem Description:
The description of APPEND on p268 is not adequately clear on the issue of what
happens if an argument to APPEND is a dotted list. The only case explicitly
mentioned is the last argument, viz:
"The last argument [to APPEND] actually need not be a list but may be any LISP
object, which becomes the tail end of the constructed list. For example, (append
'(a b c) 'd) => (a b c . d)."
While this specifies the behavior of APPEND when the last argument is not a
list, the behavior when any of the other arguments are not lists is not
specified.
Proposal (APPEND-DOTTED:REPLACE):
Define that the cdr of the last cons in any but the last argument given to
APPEND or NCONC is discarded (whether NIL or not) when preparing the list to be
returned.
In the degenerate case where there is no last cons (i.e., the argument is NIL)
in any but the last list argument, clarify that the entire argument is
effectively ignored. Point out that in this situation, if the last argument is a
non-list, the result of APPEND or NCONC can be a non-list.
Remove any text which suggests that (APPEND x '()) and (COPY-LIST x) are the
same, since these two might legitimately differ in situations involving dotted
lists. As such, deciding which to use is not just a stylistic issue.
Examples:
(APPEND '(A B C . D) '()) => (A B C) ;Proposed
(NCONC (LIST* 'A 'B 'C 'D) '()) => (A B C) ;Proposed
Note that (COPY-LIST '(A B C . D)) would still return (A B C . D).
(APPEND '(A B . C) '() 3) => (A B . 3) ;Proposed
(NCONC (LIST* 'A 'B 'C) '() 3) => (A B . 3) ;Proposed
(APPEND '() 17) => 17 ;Proposed
(NCONC (LIST) 17) => 17 ;Proposed
Rationale:
This function is used a lot and its behavior should be well-defined across
implementations. This proposal upholds the apparent status quo in a number of
implementations.
Current Practice:
Symbolics Lisp, Vaxlisp, and Lucid Lisp appear to implement the proposed
interpretation (at least in the interpreter). Franz's Allegro Common Lisp
conforms to the proposed behavior except in the case of (NCONC (LIST) 17) => 17,
where it returns NIL instead of 17.
Kyoto Common Lisp signal an error when using APPEND or NCONC on a dotted list.
Xerox Common Lisp signals an error on APPEND and implements the proposed
interpretation on NCONC.
Cost to implementors:
Technically, the change should be relatively small for those implementations
which don't already implement it. However, implementations which have microcoded
APPEND or NCONC incompatibly may find the small change somewhat painful.
Some implementations may have optimized their APPEND or NCONC to expect only NIL
when SAFETY is 0. In this case, depending on implementation details, requiring
an ATOM check rather than a NULL check may slow things down.
Cost to users:
This change is upward compatible.
Benefits:
Since non-lists are allowed as a last argument and since APPEND and NCONC can
therefore produce dotted lists, some readers may have (incorrectly) assumed that
APPEND and NCONC can reliably deal in general with dotted lists, something that
doesn't appear to be guaranteed by a strict reading. The proposed extension
would happen to legitimize such assumptions.
Aesthetics:
Whether or not users will think this improves the aesthetics of the language
will depend largely on how they view the relation between lists and dotted
lists. Those who view dotted lists as a special kind of list may feel
differently than those who view lists as a special kind of dotted list.
Discussion:
The cleanup committee supports this proposal.
∂14-Feb-88 1057 X3J13-mailer Issue: AREF-1D (Version 7)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 10:57:17 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 10:57:51 PST
Date: 14 Feb 88 10:57 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: AREF-1D (Version 7)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-105751-1238@Xerox>
This issue passed conditionally at the June 1987 meeting of X3J13. This version,
distributed in hardcopy at the November 1987 meeting, clarified some of the
details of the proposal.
!
Issue: AREF-1D
References: Arrays (pp286-298)
Category: ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
02-Jun-87, Version 2 by Pitman (ROW-MAJOR-AREF)
6-Jun-87, Versions 3, 4 by Masinter (editorial)
11-Jun-87, Version 5, to X3J13 (no changes)
6-Jul-87, Version 6, by Masinter
14-Nov-87, Version 7, by Masinter (update discussion)
Problem Description:
It's hard to write functions like Maclisp's LISTARRAY and FILLARRAY efficiently
in Common Lisp because they take arguments of varying rank. Currently, you have
to make a displaced array to work with temporarily and then throw away the
displaced array when you're done. In many cases, this is bothersome because
there is no a priori reason why they should have to cons at all.
Proposal (AREF-1D:ROW-MAJOR-AREF):
Introduce a new function ROW-MAJOR-AREF that allows one-dimensional access to
the storage backing up a given array assuming the normal row-major storage
layout.
ROW-MAJOR-AREF is valid for use with SETF.
row-major-aref array index [Function]
This accesses and returns the element of array specified by index when the
elements of array are considered in row-major order. Array may be an array of
any dimensionality. row-major-aref may be used with setf. For reference, the
following sets of expressions are equivalent:
(row-major-aref array index) ==
(aref (make-array (array-total-size array)
:displaced-to array
:element-type (array-element-type array))
index)
and
(aref array .. subscripts ..) ==
(row-major-aref array (array-row-major-index array .. subscripts ..))
Rationale:
Common Lisp requires row-major storage layout of arrays and has a number of
operators that allow users to exploit that order. ROW-MAJOR-AREF is a useful,
simple addition.
LISTARRAY and FILLARRAY, for example, could be trivially defined by loops that
had the following form:
(DOTIMES (I (ARRAY-TOTAL-SIZE ARRAY))
... (ROW-MAJOR-AREF ARRAY I) ...)
Currently, the only really efficient way to write this would involve something
like:
(ECASE (ARRAY-RANK ARRAY1)
((0) (SETF (AREF ARRAY1) (AREF ARRAY2)))
((1) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(SETF (AREF ARRAY1 I) (AREF ARRAY2 I))))
((2) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(DOTIMES (I (ARRAY-DIMENSION ARRAY 1))
(SETF (AREF ARRAY1 I J) (AREF ARRAY2 I J)))))
...some finite number of clauses...)
Current Practice:
Many implementations have this primitive under some other name for use
internally. In Symbolics systems, for example, it is SYS:%1D-AREF.
Adoption Cost:
This change is fairly localized. In implementations that already use this
primitive internally, it's little more than a matter of changing the name of or
otherwise releasing the existing primitive. In some implementations, it might
involve writing a small amount of code or compiler work to make ROW-MAJOR-AREF
work efficiently.
Benefits:
This gives users efficient access to something to which they already have
inefficient access.
Conversion Cost:
This is an upward-compatible change; the name ROW-MAJOR-AREF is unlikely to be
used by any current program.
Aesthetics:
This allows certain programs to be written in a more aesthetic way.
Discussion:
This issue was conditionally passed at X3J13/June 1987, pending clarification of
some details. Those clarifications have been made in this version.
∂14-Feb-88 1103 X3J13-mailer Issue: ASSOC-RASSOC-IF-KEY (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:03:09 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:03:31 PST
Date: 14 Feb 88 11:03 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: ASSOC-RASSOC-IF-KEY (Version 4)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-110331-1248@Xerox>
This issue is new.
!
Issue: ASSOC-RASSOC-IF-KEY
References: ASSOC-IF (p280), ASSOC-IF-NOT (p280), RASSOC-IF (p281),
RASSOC-IF-NOT (p281)
Category: ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
20-Nov-87, Versions 2,3 by Masinter
23-Nov-87, Version 4 by Masinter
Problem Description:
The descriptions of ASSOC-IF, ASSOC-IF-NOT, RASSOC-IF, and RASSOC-IF-NOT do not
mention a :KEY option, although ASSOC and RASSOC have one.
This is often reported as an inconsistency in Common Lisp.
Proposal (ASSOC-RASSOC-IF-KEY:YES):
Allow a :KEY keyword for ASSOC-IF, ASSOC-IF-NOT, RASSOC-IF, and RASSOC-IF-NOT.
If not supplied, it should default to #'IDENTITY as do the :KEY keywords for
other -IF and -IF-NOT functions. The function, as with the :KEY argument for
ASSOC and RASSOC, is applied to the CAR of the pair in the association list for
ASSOC-IF and ASSOC-IF-NOT and the CDR of the pair for RASSOC-IF and
RASSOC-IF-NOT.
Documentation impact:
A better description of the intent might be to say that the car /contains/ the
key of the association, and by default the car /is/ the key of the association.
Example:
(assoc-if #'zerop pathnames :key #'pathname-version)
could be used to search a list indexed by pathnames finding one with zero
version.
Rationale:
This is an inconsistency in the language that is simple to fix.
Current Practice:
Symbolics implements :KEY for the -IF and -IF-NOT assoc functions. Others follow
the book and allow :KEY only for ASSOC.
Cost to Common Lisp implementors:
A small amount of additional code is necessary to support this in
implementations not already offering it as an extension.
Cost to Common Lisp users:
The change is essentially upward compatible with user code.
Benefits:
This would make the set of -IF and -IF-NOT functions be more regular in their
calling conventions.
Aesthetics:
All the other -IF and -IF-NOT variations of list operations omit the :TEST and
:TEST-NOT keywords, but allow :KEY. For example, consider the family of MEMBER,
MEMBER-IF, and MEMBER-IF-NOT. Although this introduces additional mechanism, it
does so in a way that probably makes it easier to think about which functions do
what, so it would likely be seen as a simplification.
Discussion:
The omission of :KEY in this situation in CLtL was probably an oversight.
The cleanup committee supports this proposal.
∂14-Feb-88 1109 X3J13-mailer Issue: COLON-NUMBER (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:08:51 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:08:44 PST
Date: 14 Feb 88 11:08 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: COLON-NUMBER (Version 1)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-110844-1256@Xerox>
This issue was distributed in hardcopy at the November 1987 meeting of X3J13.
!
Issue: COLON-NUMBER
References: Parsing of Numbers and Symbols (p339-341, 343-344)
Category: CLARIFICATION
Edit history: 22-Oct-87, Version 1 by Pitman
Problem Description:
CLtL is unclear about whether a colon followed by a potential number is a
potential number. There are passages which seem to address this issue
unambiguously but fail.
Proposal (COLON-NUMBER:UNDEFINED):
Clarify that syntax involving a leading colon followed by a potential number is
not well-defined. That is, use of notation such as :1, :1/2, and :2↑3 in a
position where an expression appropriate for READ is expected is an error.
Rationale:
This makes the status quo apparent.
Current Practice:
Some implementations, such as Symbolics Lisp, claim the right to interpret this
as an ``is an error'' situation where their upward-compatible extension is to
parse ``:1'' as the number 1 (incidentally, but uninterestingly, expressed in
the KEYWORD package).
Other implementations tokenize ``:1'' as a single token, identify it as a
symbol, and then parse it as :\1 would be parsed.
Cost to implementors:
None. This clarification forces no implementations to change.
Cost to users:
Slight. Some users may have mistakenly believed that this was an aspect of the
language that was guaranteed and may have written programs that exploited that
belief. Such incidences are probably very rare, however. Also, even in the few
cases where such code fortuitously worked, implementations are likely to
continue to support it so such code will probably continue to fortuitously work
in many of those rare situations.
Benefits:
Programmer expectations that any useful behavior can be portably relied upon in
this pathological case should be soundly trounced.
Aesthetics:
Arguably a slight improvement in visual aesthetics. What was already a pretty
marginal syntax is discouraged.
Discussion:
Pitman supports this clarification. He thinks this issue is not a big deal, but
it does crop up often enough to be a nuisance. It would be nice to have everyone
acknowledge a unified position, even if that only meant agreeing to disagree.
∂14-Feb-88 1112 X3J13-mailer Issue COMPILER-WARNING-BREAK (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:12:51 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:13:23 PST
Date: 14 Feb 88 11:13 PST
From: Masinter.pa@Xerox.COM
Subject: Issue COMPILER-WARNING-BREAK (Version 4)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.stanford.edu
Message-ID: <880214-111323-1266@Xerox>
This issue has not been distributed to X3J13 before.
!
Issue: COMPILER-WARNING-BREAK
References: COMPILE (p438), COMPILE-FILE (p439)
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by Pitman 02/27/87
Version 2 by cleanup committee 15-Mar-87 14:25:03
Version 3 by Masinter 5-Jun-87
Version 4 by Masinter 23-Nov-87
Problem Description:
The description of the COMPILE and COMPILE-FILE functions does not say whether
*BREAK-ON-WARNINGS* affects warnings output by the compiler. If this is to be
allowed, it should be an explicitly expressed part of the contract.
Proposal (COMPILER-WARNING-BREAK:YES):
The definitions of COMPILE and COMPILE-FILE should state that these functions
are required to break on warnings if *BREAK-ON-WARNINGS* is true (just as if it
calls WARN).
Note: User interface commands provided by particular vendor implementations
which implicitly call COMPILE or COMPILE-FILE could bind *BREAK-ON-WARNINGS*
back to NIL if they felt it important to not break for some reason relating to
cultural compatibility. This would not interfere with the proposed new semantics
for the functions COMPILE and COMPILE-FILE.
Rationale:
*BREAK-ON-WARNINGS* is defined to cause the debugger to be entered when warnings
occur. If the compiler is permitted to warn (separate ballot item), the effect
of this variable on compiler warnings should be nailed down.
Current Practice:
Some compilers respect *BREAK-ON-WARNINGS* and others probably do not.
Adoption Cost:
Those compilers which do not use WARN directly but some other mechanism might
have to be edited, but it would not be a major change.
Conversion Cost:
Probably little or no user code would be affected by this change.
Benefits:
This would make the language definition more consistent by making it less
subject to special cases. Portable programs can be assured of consistent
behavior when dealing with the compiler.
Aesthetics:
Most users will probably perceive this change as a simplification because it
will allow the kind of warning that comes from WARN and the kind of warning that
comes from compilation to be conceptually grouped.
Discussion:
*BREAK-ON-WARNINGS* and the compiler are part of the environment rather than the
language.
We considered but rejected the notion of a separate
*COMPILER-BREAK-ON-WARNINGS*. It is possible that with the adoption of a
signal/error system that the *BREAK-ON-WARNINGS* mechanism could be replaced in
its entirity by a more structured signal/handler structure, making this proposal
moot.
∂14-Feb-88 1122 X3J13-mailer Issue: DECLARE-MACROS (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:22:36 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:21:29 PST
Date: 14 Feb 88 11:21 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: DECLARE-MACROS (Version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Line-fold: no
reply-to: cl-cleanup@Sail.stanford.edu
Message-ID: <880214-112129-1276@Xerox>
This issue was distributed in hardcopy at the November 1987 meeting.
There was some opposition at that time. This version includes a more
extensive description of possible alternative coding practices.
!
Issue: DECLARE-MACROS
References: Declaration Syntax (p154)
Category: CHANGE
Edit history: 22-Oct-87, Version 1 by Pitman
9-Nov-87, Version 2 by Masinter
5-Feb-88, Version 3 by Pitman
Problem Description:
It is permissible for a macro call to expand into a declaration and be
recognized as such. This linguistic feature provides some useful
flexibility, but has a number of disadvantages:
* Operations on the executable portion of a body of code inside a
binding form (such as inserting an additional form) is a complicated
operation. This is because one or more trial macro expansions must be
done in order to pass over any declarations or documentation string
and find the beginning of the body.
* In order to find the end of the declarations, MACROEXPAND must be
called until a non-macro form is seen or until a macro does not expand
into a macro. In some interpreters which do macro expansion on the fly,
this may cause inefficiency because macro expansion of the first form
in a body must be done twice. In implementations where this is
optimized, the implementor may resent the fact that an optimization is
needed in the first place.
* Various code analysis tools have been shown to have been significantly
slowed down by the need to expand macros in order to determine whether
a binding is SPECIAL when analyzing a variable binding form. This is
particularly serious when macro invocations are deeply nested; the
number of macro expansions can be exponential in the depth of nesting
unless a macro-expansion caching mechanism is added.
* User macros must be very careful about finding declarations in a body
of code by doing proper macro expansion. Often, however, naive users
don't realize this and so unknowingly write buggy code. This problem can
be (and is) defined away as simply a programmer error, but this is a
place where we could fairly straightforwardly redefine the language to
better accommodate what has been shown to be a common expectation of the
naive user.
Proposal (DECLARE-MACROS:FLUSH):
Under this proposal, it would not be "permissible for a macro call to
expand into a declaration and be recognized as such, provided that the
macro call appears where a declaration may legitimately appear." (CLtL
p. 154). Macros could not legitimately expand into declarations; the only
valid declarations would be a list whose CAR is the symbol DECLARE.
It would still be possible for a macro call to expand into a PROCLAIM
form, however.
Rationale:
The ability to have a macro form expand into a declaration has been shown
to be useful in some situations. More often, however, the presence of
this feature has been seen to cause problems elsewhere in the language.
Ultimately, its benefits have not outweighed its costs.
Current Practice:
Most or all implementations support the old behavior even though few
user programs probably need it.
Some user macros are careful about finding declarations in a body of code
by doing proper macro expansion, but some probably cheat and look just
for explicit uses of DECLARE. The cheat probably works most of the time.
Cost to implementors:
The nature of this change is such that implementations which did not
choose to change would simply be supporting an implementation-dependent
extension (except for some `minor' worry about destructive modification
due to macro expanding while *MACROEXPAND-HOOK* is set to something
which implemented displacing macros).
In any case, there might be several places in which the interpreter,
compiler, and system macros had knowledge about doing macro expansion
before declaration processing. The change is not trivial, but most of
its complexity is likely to be in finding the places which need change
and not in making the actual change.
Cost to users:
Most users probably do not write macros which expand into DECLARE forms
so most users are probably not affected.
Users who do exploit this feature probably know that they do. In any
case, compilers could be made to detect cases where this feature is
being exploited and warn about it.
Franz and Gold Hill are notable exceptions to the claim that users may
not want this. Both claim to make a reasonable amount of use of macros
which expand into different SPEED and SAFETY declarations, usually
dependent on a global switch.
Rewrites must be devised on a case-by-case basis. A common sort of
rewrite would take the form:
Old code: (DEFMACRO SPEEDY ()
`(DECLARE (OPTIMIZE (SPEED 3) (SAFETY 0))))
(LET (..bindings..) (SPEEDY) ..body..)
New code: (DEFMACRO SPEEDY-LET (BVL &BODY FORMS)
`(LET ,BVL
(DECLARE (OPTIMIZE (SPEED 3) (SAFETY 0)))
,@FORMS))
(SPEEDY-LET (..bindings..) ..body..)
Another tactic would be:
Old code: (EVAL-WHEN (EVAL COMPILE LOAD)
(DEFVAR *SPEEDY* NIL))
(DEFMACRO USE-STANDARD-SPEED-AND-SAFETY ()
(IF *SPEEDY*
`(DECLARE (OPTIMIZE (SPEED 3) (SAFETY 0)))
`(DECLARE (OPTIMIZE (SPEED 0) (SAFETY 3)))))
(DEFUN FOO ()
(USE-STANDARD-SPEED-AND-SAFETY)
...)
New code: (EVAL-WHEN (EVAL COMPILE LOAD)
(DEFVAR *STANDARD-SPEED-AND-SAFETY* '((SPEED 0) (SAFETY 3))))
(DEFUN FOO ()
(DECLARE (OPTIMIZE #.*STANDARD-SPEED-AND-SAFETY*))
...)
Still a third tactic would be to actually shadow DEFUN, LET, etc. with
variants that process macro expansions and then to build code in a
package that used the revised DEFUN, LET, etc. eg,
(DEFUN PARSE-BODY (BODY ENV)
(LET ((DECLS '())
(DOC '()))
(DO () ((NULL (CDR BODY)))
(LET ((EXP (MACROEXPAND (POP BODY) ENV)))
(COND ((AND (STRINGP EXP) BODY)
(UNLESS (NULL DOC)
(WARN "More than one documentation string was seen."))
(PUSH EXP DOC))
((AND (NOT (ATOM EXP)) (EQ (CAR EXP) 'DECLARE))
(PUSH EXP DECLS))
(T
(PUSH EXP BODY)
(RETURN NIL)))))
(VALUES BODY (NREVERSE DECLS) (NREVERSE DOC))))
(DEFMACRO MY:DEFUN (NAME LAMBDA-LIST &BODY DECLS-DOC-AND-FORMS
&ENVIRONMENT ENV)
(MULTIPLE-VALUE-BIND (FORMS DECLS DOC-STRINGS)
(PARSE-BODY DECLS-DOC-AND-FORMS ENV)
`(DEFUN ,NAME ,BVL ,@DECLS ,@DOC-STRINGS ,@FORMS)))
(DEFMACRO MY:LET (BINDINGS &BODY DECLS-DOC-AND-FORMS
&ENVIRONMENT ENV)
(MULTIPLE-VALUE-BIND (FORMS DECLS DOC-STRINGS)
(PARSE-BODY DECLS-DOC-AND-FORMS ENV)
`(LET ,BINDINGS ,@FORMS)))
...etc.
LAMBDA cannot be done this way, of course, since it is not a macro (or
even a special form). Support for expanding declarations in a LAMBDA
would have to be provided either by using implementation-specific support
(such as Zetalisp's ``lambda macros'') or by a workaround such as a
macro like:
(DEFMACRO LAMBDA (LAMBDA-LIST &BODY DECLS-DOC-AND-FORMS
&ENVIRONMENT ENV)
(MULTIPLE-VALUE-BIND (FORMS DECLS DOC-STRINGS)
(PARSE-BODY DECLS-DOC-AND-FORMS ENV)
`#'(LAMBDA ,BINDINGS ,@FORMS)))
Note that unlike the other examples, LAMBDA need not be (and in fact,
may not be) in the "MY" package in order for this to work since the
FUNCTION special form will generally only recognize LISP:LAMBDA.
Benefits:
The efficiency of some tools may be improved.
User macros which must do minor surgery on bodies of code will be
easier to write.
Aesthetics:
This change simplifies the semantics of the language slightly and
probably tends to better support the assumptions of naive programmers
writing macros.
In some cases involving complicated extensions to declarations, it
may be slightly harder to express such extensions in a modular way.
Experience thus far has shown such cases to be rare, however.
Discussion:
Symbolics took an in-house poll of people who take advantage of the
feature and it was generally agreed that in most cases where this
feature is used at all, that it would be just as easy to work around
using the sample rewrite techniques cited above.
Moon `credits' Pitman for (against some opposition) pushing this
`feature' down everyone's throats in the original CL design process.
Pitman admits this was an expensive mistake. Moon and Pitman support
this change as an important simplification to the language.
The cleanup committee unanimously endorsed this proposal.
In discussion at the Nov-87 X3J13 meeting, Franz and Gold Hill
mentioned that they use this feature a lot and were not entirely
happy about its going away.
∂14-Feb-88 1125 X3J13-mailer Issue: DEFVAR-DOCUMENTATION (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:25:02 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:25:36 PST
Date: 14 Feb 88 11:25 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFVAR-DOCUMENTATION (Version 2)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.stanford.edu
Message-ID: <880214-112536-1283@Xerox>
An earlier version of this issue was distributed at the November 1987 meeting.
!
Issue: DEFVAR-DOCUMENTATION
References: DEFVAR, DEFPARAMETER, DEFCONSTANT (pp68-9)
Category: CLARIFICATION
Edit history: 30-Jun-87, Version 1 by Pitman
23-Nov-87, Version 2 by Masinter
Problem Description:
CLtL is not explicit about whether the documentation part of DEFVAR,
DEFPARAMETER, and DEFCONSTANT special forms is evaluated.
Proposal (DEFVAR-DOCUMENTATION:UNEVALUATED):
Clarify that the documentation part of DEFVAR, DEFPARAMETER, and DEFCONSTANT
special forms is not evaluated. That is, it must be a literal string, not a form
which evaluates to a string.
Examples:
(DEFVAR *MY-VARIABLE* (CONSTRUCT-INITIAL-VALUE) "A documentation string") ; OK
(DEFVAR *MY-VARIABLE* (CONSTRUCT-INITIAL-VALUE) GENERIC-DOCUMENTATION-STRING) ;
would be an error
Rationale:
To ensure portability, implementations must agree on whether or not this
position is evaluated. Specifying that the position is unevaluated is the
conservative thing to suggest, and consistent with the (unevaluated)
documentation strings in DEFUN, DEFSTRUCT.
Current Practice:
Some implementations evaluate this position. Others do not.
Cost to implementors:
Implementations that did not already check might usefully add a check in the
macro expansion for DEFVAR, DEFPARAMETER and DEFCONSTANT to assert that the
DOCUMENTATION, if supplied, was a string. The change is likely trivial.
Cost to users:
Code which uses other than a literal string is not portable, so no portable
programs will be broken. Some non-portable programs which rely on a particular
vendor's interpretation would have to be rewritten. Automatic tools to detect
most offending cases could trivially be constructed. (We know of no current
uses.)
Benefits:
Code portability would be improved. Some programming environment tools might
assume that documentation strings were determinable without evaluation.
Aesthetics:
Slight improvement; this implies consistent treatment for documentation strings
in all defining forms.
Discussion:
We think this is a good idea.
∂14-Feb-88 1130 X3J13-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:30:43 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:31:18 PST
Date: 14 Feb 88 11:30 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-113118-1288@Xerox>
This issue has not been distributed before. It is originally from Steele's list.
!
Issue: DISASSEMBLE-SIDE-EFFECT
References: DISASSEMBLE (p. 439), COMPILE (p. 439)
Category: CLARIFICATION
Edit history: Version 2 by Pierson 12/30/87
Version 3 by Pierson 1/21/88
Problem description:
The definition of DISASSEMBLE says that "if the relevant function is not a
compiled function, it is first compiled.". The definition of COMPILE says that
"If name is a non-nil symbol, then the compiled-function is installed as the
global function definition of the symbol...". Several implementations have
taken this to mean that if DISASSEMBLE is passed a symbol which has an
uncompiled function definition, then it has the side-effect of (COMPILE
'symbol).
Proposal (DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL):
Clarify that when DISASSEMBLE compiles a function, it will never install the
newly compiled function.
Example:
(DEFUN F (A) (1+ A))
(EQ (SYMBOL-FUNCTION 'F)
(PROGN (DISASSEMBLE 'F)
(SYMBOL-FUNCTION 'F)))
This code will return T if this proposal is adopted. Some current
implementations will return T, some will return NIL.
Rationale:
Several current implementations of DISASSEMBLE have surprising side effects,
especially for new users.
Current practice:
Allegro CL and Vax Lisp install the compiled definition. Lucid, Symbolics,
Xerox, and KCL don't install it.
Cost to Implementors:
Some implementations will have to make a simple change.
Cost to Users:
Very little. DISASSEMBLE is really part of the environment and is probably not
called by much, if any user code.
Cost of non-Adoption:
DISASSEMBLE will continue to surprise less experienced users.
Benefits:
DISASSEMBLE will become the predictable debugging function it was meant to be.
Aesthetics:
Some who worried that DISASSEMBLE was supposed to install the compiled function
may find that the language has become a little cleaner.
Discussion:
DISASSEMBLE is an environment feature; some question has been raised as to the
place and force of environment features in the standard. However, this proposal
stands if DISASSEMBLE is part of the standard language.
∂14-Feb-88 1137 X3J13-mailer Issue: DO-SYMBOLS-DUPLICATES (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:37:23 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:37:58 PST
Date: 14 Feb 88 11:37 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: DO-SYMBOLS-DUPLICATES (Version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-113758-1303@Xerox>
This issue has not been distributed to X3J13 before.
!
Issue: DO-SYMBOLS-DUPLICATES
References: DO-SYMBOLS, CLtL p.187
Category: Clarification
Edit history: Version 1 by Fahlman 17-Apr-87
Version 2 by Masinter 29-May-87
Version 3 by Masinter 23-Nov-87
Problem Description:
CLtL specifies that DO-SYMBOLS executes the body once for each symbol accessible
in the package. It does not say whether it is permissible for the body to be
executed more than once for some accessible symbols. The term "accessible" is
defined on page 172 to include symbols inherited from other packages (not
including any symbols that may be shadowed). It is very expensive in some
implementations to eliminate duplications that occur because the same symbol is
inherited from multiple packages.
Proposal: DO-SYMBOLS-DUPLICATES:ALLOWED
Add to the specification of DO-SYMBOLS a note that it may execute the body more
than once for some symbols.
Example:
(SETQ A (MAKE-PACKAGE 'A))
(SETQ B (MAKE-PACKAGE 'B))
(EXPORT (INTERN "ASYM" A) A)
(USE-PACKAGE A B)
(EXPORT 'B::ASYM B)
(USE-PACKAGE B A)
(DO-SYMBOLS (X B) (PRINT X))
;; this may print ASYM once or twice.
Rationale:
Most uses of DO-PACKAGE would not be harmed by the presence of duplicates. For
these applications it is unreasonable to force users to pay the high cost of
filtering out the duplications. Users who really want the duplicates to be
removed can add additional code to do this job.
Current Practice:
Many implementations have always produced duplicate values.
Cost to implementors:
None. Implemenations would still be free to eliminate the duplications, though
code will not be assuming that this has been done.
Cost to users:
Code written assuming that DO-SYMBOLS eliminates duplications will have to be
modified. (Such code was not truly portable.)
Benefits:
Clarification of a situation that is currently ambiguous.
Aesthetics:
It would be cleaner to present each symbol exactly once. This is a clear case
of choosing efficiency over elegance.
Discussion:
This issue was discussed on the Common Lisp mailing list in 1985, and the
solution proposed here seems to have been informally agreed to at the time --
there was no formal decision-making process in place then.
The need for DO-SYMBOLS to be efficient is questionable, however; for many
applications (e.g., global package manipulation), duplicate values would create
havoc.
For some implementations, the performance penalty would be well over a factor of
two.
Several proposals were considered for adding keyword arguments to DO-SYMBOLS
which might specify :ALLOW-DUPLICATES, adding keywords and eliminating
DO-EXTERNAL-SYMBOLS, etc., but no clear consensus was reached for making
additions.
This version is the closest to the status quo.
∂14-Feb-88 1155 X3J13-mailer Issue: DRIBBLE-TECHNIQUE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:55:29 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:55:39 PST
Date: 14 Feb 88 11:55 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: DRIBBLE-TECHNIQUE (Version 2)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-115539-1321@Xerox>
This issue has not been distributed before. (In fact, this version had not been
distributed to the cleanup committee.) There was no discussion on the issue,
however.
!
Issue: DRIBBLE-TECHNIQUE
References: DRIBBLE (p443)
Category: CLARIFICATION
Edit history: 06-Dec-87, Version 1 by Pitman
14-Feb-88, Version 2 by Masinter
Problem Description:
The intent and effect of DRIBBLE is not very clearly specified. Users have
complained that DRIBBLE behaves quite differently in different implementations.
Proposal (DRIBBLE-TECHNIQUE:MAKE-EXPLICITLY-VAGUE):
Clarify that DRIBBLE is intended primarily for interactive debugging and that
its effect cannot be relied upon from programs.
Test Case:
#1: (PROGN (DRIBBLE "temp")
(PRINT 'FOO)
(DRIBBLE))
#2: (DRIBBLE "temp")
(PROGN (PRINT 'FOO)
(DRIBBLE)
(PRINC 'BAR))
Rationale:
Users of DRIBBLE have been surprised about how differently DRIBBLE behaves in
different implementations. This makes the status quo much more explicit and will
lead to less surprise.
Current Practice:
Some implementations implement DRIBBLE as a function which simply assigns
streams such as *STANDARD-OUTPUT* to broadcast streams (or the approximate
equivalent thereof). Even within this camp, there is not widespread agreement
about which streams are affected. However, typically test case #1 will capture
the output of (PRINT 'FOO) in the file "temp" and will execute (PRINT 'BAR) but
not capture its output.
Some implementations (eg, Symbolics) push to a recursive command loop when
DRIBBLE is called with an argument, and return from that command loop when
DRIBBLE is called with no argument. In these implementations, test case #1 will
enter a recursive command loop upon the first call to DRIBBLE and will not
execute the (PRINT 'FOO) until (DRIBBLE) is done interactively. When the second
(DRIBBLE) in test case #1 is executed, DRIBBLE will complain that output is not
currently being recorded. In test case #2, the output of (PRINT 'FOO) will be
captured, but the form (PRINT 'BAR) will never be executed because (DRIBBLE)
does not return normally (it throws).
Cost to implementors:
None. This is just a clarification.
Cost to users:
Anyone who currently uses DRIBBLE in code that is believed to be portable is
kidding himself. If such code works in some implementations, it can continue to
work.
Benefits:
Users will be aware that they cannot rely on DRIBBLE in portable code.
Aesthetics:
No apparent effect.
Discussion:
DRIBBLE, like other environment features, is a standard interface to a
non-standard feature. As such, there is some question as to its place in the
ANSI standard. However, if DRIBBLE remains in the standard, its behavior is made
explicitly vague by this proposal.
∂14-Feb-88 1201 X3J13-mailer Issue: FLET-DECLARATIONS (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 12:01:21 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:00:15 PST
Date: 14 Feb 88 11:59 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: FLET-DECLARATIONS (Version 2)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-120015-1323@Xerox>
!
Issue: FLET-DECLARATIONS
References: FLET, LABELS, MACROLET (CLtL p.113)
X3J13 document 86-003 item 113
Cleanup issue DECLARATION-SCOPE.
Cleanup issue DECLARE-MACROS.
Category: ADDITION
Edit history: Version 1, Moon, 1 Jan 1988
Version 2, Moon, 2 Feb 1988 (edits suggested by Masinter)
Problem description:
Declarations are not allowed before the body of FLET, LABELS, and MACROLET, even
though Common Lisp allows declarations in other seemingly analogous places, such
as LET.
Proposal (FLET-DECLARATIONS:ALLOW):
Change the syntax of FLET, LABELS, and MACROLET to allow declarations between
the list of local function/macro definitions and the body forms.
The scope of such declarations in FLET and LABELS includes the bodies of the
locally defined functions, when the declarations are pervasive. Non-pervasive
declarations have no effect on those bodies, except when LABELS includes the
body in the scope of a function non-pervasively declared. This paragraph
follows directly from CLtL p.155 if the locally defined function bodies are
treated like initialization forms. (This paragraph will be superseded by cleanup
issue DECLARATION-SCOPE if it passes.)
The scope of such declarations does not include the bodies of the macro expander
functions defined by MACROLET. This is consistent with the existing rule that
the bodies of those functions are in the global environment, not the local
lexical environment.
If cleanup issue DECLARE-MACROS is not passed, in MACROLET an invocation of one
of the macros locally defined by that MACROLET is permitted to expand into a
DECLARE.
Example:
(defun example (y l)
(flet ((attach (x)
(setq l (append l (list x)))))
(declare (inline attach))
(dolist (x y)
(unless (null (cdr x))
(attach x)))
l))
(example '((a apple apricot) (b banana) (c cherry) (d) (e))
'((1) (2) (3) (4 2) (5) (6 3 2)))
=> ((1) (2) (3) (4 2) (5) (6 3 2) (a apple apricot) (b banana) (c cherry))
The above function is erroneous in current Common Lisp. With this proposal, it
would have an intuitively obvious meaning.
Rationale:
This will make the syntax of FLET and LET consistent. This will make it
possible to attach declarations to function bindings; currently only variable
bindings can have attached declarations.
Current practice:
Xerox Common Lisp implements FLET-DECLARATIONS:ALLOW. Symbolics Common Lisp does
not allow declarations in this position.
Cost to Implementors:
The compilation and interpretation of three special forms will have to be
changed, however the same techniques already developed for declarations in LET
should be applicable.
Cost to Users:
No cost since this is an upward-compatible addition.
Cost of non-adoption:
Unnecessary inconsistency in the syntax of Common Lisp.
Benefits:
There is no major benefit but the language will be more consistent.
Esthetics:
Makes the language more consistent.
Discussion:
We need to resolve this for CLOS, because CLOS introduces two new special forms
similar to FLET and LABELS and we need to make their syntax consistent with FLET
and LABELS.
∂14-Feb-88 1204 X3J13-mailer Issue: FORMAT-COMMA-INTERVAL (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 12:03:49 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:04:24 PST
Date: 14 Feb 88 12:04 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: FORMAT-COMMA-INTERVAL (Version 2)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-120424-1324@Xerox>
This issue is new.
!
Issue: FORMAT-COMMA-INTERVAL
References: FORMAT integer printing (p. 388-9)
Category: ADDITION
Edit history: Version 1, Pavel, 10-Jun-87
Version 2, Masinter, 15-Jun-87
Problem description:
There are times when users would like to print out numbers with some punctuation
between groups of digits. The "commachar" argument to the ~D, ~B, ~O, ~X, and
~R FORMAT directives was introduced to fill that need. Unfortunately, the
interval at which the commachar should be printed is always every three digits.
This constraint is annoying when a different interval would be more appropriate.
Proposal (FORMAT-COMMA-INTERVAL:YES):
Add a fourth argument to the ~D, ~B, ~X, and ~O FORMAT directives, and a fifth
argument to the ~R directive, to be called the "comma-interval". This value
must be an integer and defaults to 3. When the : modifier is given to any of
these directives, the "commachar" is printed between groups of "comma-interval"
digits.
Test Cases:
Under the proposal, the following forms return the indicated values:
(format nil "~,,' ,4:B" 13) => "1101"
(format nil "~,,' ,4:B" 17) => "1 0001"
(format nil "~19,0,' ,4:B" 3333) => "0000 1101 0000 0101"
(format nil "~3,,,' ,2:R" 17) => "1 22"
(format nil "~,,'|,2:D" #xFFFF) => "6|55|35"
Rationale:
The current specification of FORMAT gives the user control over almost all of
the facets of printing integers. Only the wired-in constant for the
comma-interval remains, even though there are uses for varying that number. For
example, in many contexts, it would be convenient to be able to print out
numbers in binary with a space between each group of four bits. FORMAT does not
currently allow specification of the commachar printing interval so users
needing this functionality must write it themselves, duplicating much of the
logic in every implementation's integer printing code. Other uses, requiring
other intervals, can be imagined. For example, using a "commachar" of #\Newline
and a "comma-interval" of, say, 72, very large bignums could be printed in such
a way as to ensure line-breaks at appropriate places.
Current practice:
No released implementations currently support this feature.
Cost to implementors:
The change in the implementation of FORMAT is reasonably minor and, in most
cases, highly localized. Usually, the change is as simple as taking an extra
parameter and using it instead of a wired-in value of 3.
Cost to users:
Since the proposal involves the addition of an argument to certain directives,
the change would be entirely upward-compatible. No user code would need to be
converted.
Cost of non-adoption:
Users desiring this functionality will have to write it themselves, duplicating
much of the logic involved in printing integers at all.
Benefits:
One of the few remaining inflexibilities in integer printing is eliminated with
a net increase in user-visible functionality.
Esthetics:
By parameterizing one of the final pieces of wired-in behavior from integer
printing, this small part of the workings of FORMAT would be perceived as having
been cleaned up.
Discussion:
Several members of the cleanup committee endorsed this proposal. No objections
were raised.
∂14-Feb-88 1214 X3J13-mailer Issue: FORMAT-COLON-UPARROW-SCOPE (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 12:14:19 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:14:54 PST
Date: 14 Feb 88 12:14 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: FORMAT-COLON-UPARROW-SCOPE (version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-121454-1351@Xerox>
This issue is new.
!
Issue: FORMAT-COLON-UPARROW-SCOPE
References: CLtL p. 406 and also p. 403
Category: CLARIFICATION
Edit history: version 1: Guy Steele, 30 November 1987
version 2: Guy Steele, 18 January 1988
version 3: Masinter, 5 February 1988
Problem description:
Implementations currently differ on the question of what is tested by the FORMAT
command "~:↑". Some implementations test to see whether any arguments remain in
the sublist for the current iteration step; others test to see whether any
sublists remain. The text on page 406 is not clear on this point.
Proposal (FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS):
~:↑ may be used only if the command it would terminate is ~:{ or ~:@{. The
entire iteration process is terminated if and only if the sublist that is
supplying the arguments for the current iteration step is the last sublist (in
the case of ~:{) or the last FORMAT argument (~:@{). Note that ~:↑ is *not*
equivalent to ~:#↑; the latter terminates the entire iteration if and only if no
arguments remain for the current iteration step.
Example:
(format nil "~:{~@?~:↑...~}" '(("a") ("b")))
Under this proposal, this yields "a...b", rather than "a".
Rationale:
This proposal is desirable because otherwise there is no way to test whether any
sublists remain. The text on page 406 may be construed to hint at this proposal
indirectly. To quote Nick Gall:
"If one thinks about the intent of the parenthetical `(because in the standard
case it tests for remaining arguments of the current step only)', one should
agree that "a...b" will be returned. In referring to ~↑ as the `standard case',
which tests the arguments remaining in the current argument sublist, this
parenthetical implies that there is an `other case', which tests `something
else.' The only `other case' discussed is ~:↑, which therefore must test
`something else.' I claim that the parentheical makes no sense if we interpret
~:↑ as testing the same condition as ~↑. If they both test the same condition,
why have the parenthetical explanation?
"If ~:↑ doesn't test the same condition as ~↑, then what does it test? I claim
that the only test that makes sense is for ~:↑ to test the only thing that
affects the `entire iteration process:' the number of sublists. When there are
no more sublists, `the entire iteration process' is terminated."
Current practice:
Some implementations already have the proposed behavior, including Symbolics
Common Lisp and TI Lisp.
Many other implementations currently have a different interpretation: the test
case returns "a", since ~:↑ in those implementations test for the remaining
arguments rather than remaining sublists. These currently include Kyoto Common
Lisp, Allegro Common Lisp, GCLISP, Xerox Common Lisp, Spice Lisp, and VAXLISP.
Cost to Implementors:
Many implementations will have to make a small change, probably a one-liner.
Cost to Users:
It is unlikely that much user code depends on the behavior of testing for
remaining arguments, but it is possible. The author of this writeup (Steele)
judges it somewhat more likely that user code might depend on the behavior of
testing for remaining sublists.
Cost of non-adoption:
Users would have to be warned not to use ~:↑ in code that is meant to be
portable.
Benefits:
Elimination of yet one more ambiguity. The proposed semantics allows greater
semantic power (there are more things one can test).
Esthetics:
``Absolutely none. We're talking about FORMAT here.'' -- Guy L. Steele Jr.
Discussion:
Guy Steele very strongly prefers the interpretation
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.
David Moon, Kent Pitman, Pavel Curtis, Dan Pierson, Rob Poor, Scott Fahlman and
Nick Gall favor FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.
Kevin Layer and Rich Robbins have spoken in favor of an alternative proposal, to
test for the remaining arguments.
Historical note: Steele first implemented this "feature", in Zetalisp, and so
the code in Symbolics Common Lisp is likely a direct descendant of the original
code. This might cause some to give weight to Steele's opinion. There are two
arguments against such credence. First, there is no reason why the original
code should be regarded as part of the specification of Common Lisp any more
than any other implementation; plainly, Steele botched the specification when he
wrote the book. Second, a professor of literature (I believe) once told Isaac
Asimov concerning a short story of his (I quote from memory): "Tell me, Dr.
Asimov, just because you wrote the story, what makes you think you know what it
means?"
∂14-Feb-88 1223 X3J13-mailer Issue FUNCTION-TYPE-KEY-NAME, Version 3
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 12:23:25 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:23:55 PST
Date: 14 Feb 88 12:23 PST
From: Masinter.pa@Xerox.COM
Subject: Issue FUNCTION-TYPE-KEY-NAME, Version 3
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-122355-1354@Xerox>
This issue is new.
!
Issue: FUNCTION-TYPE-KEY-NAME
References: CLtL p.47-48, 61
Category: CLARIFICATION, CHANGE
Edit history: Version 1, 23-Nov-1987 Sandra Loosemore
Version 2, 15-Jan-1988 Sandra Loosemore
(from comments by Kent Pitman)
Version 3, 13-Feb-88 Masinter
Related issues: FUNCTION-TYPE-REST-LIST-ELEMENT,
KEYWORD-ARGUMENT-NAME-PACKAGE
FUNCTION-ARGUMENT-TYPE-SEMANTICS
Problem description:
The FUNCTION type specifier list is provided to allow declaration of function
argument types and return value types. This type specifier uses a syntax
similar to the usual lambda list syntax to specify which types go with which
lambda list variables. However, there is a problem with &KEY lambda variables
because CLtL does not specify how the types specified in the FUNCTION
declaration are matched up to either the actual arguments passed to the
function, or the lambda variables in the function definition (since the ordering
of keyword arguments is arbitrary).
Proposal (FUNCTION-TYPE-KEY-NAME:SPECIFY-KEYWORD):
(1) Specify that the &KEY parameters in a FUNCTION type specifier lambda list
should be supplied as lists of the form (<keyword> <type>). The <keyword> must
be a valid keyword-name symbol as must be supplied in the actual arguments of a
call. (This is usually a symbol in the keyword package, but, as per
KEYWORD-ARGUMENT-NAME-PACKAGE, not necessarily so.)
(2) Allow &ALLOW-OTHER-KEYS to appear in a FUNCTION type specifier lambda list.
The interpretation of such declarations is that, when &KEY is given in a
FUNCTION type specifier lambda list, it is safe to assume that the &KEYs given
are exhaustive unless &ALLOW-OTHER-KEYS is present.
&ALLOW-OTHER-KEYS is an indication that other keyword arguments may actually be
supplied and, if supplied, may be used.
Example:
The type of the function MAKE-LIST could be declared as:
(FUNCTION MAKE-LIST ((INTEGER 0) &KEY (:INITIAL-ELEMENT T)) LIST)
Rationale:
(1) This specifies a direct correspondence between the argument type and its
matching keyword. All of the information is in one place, and the user does not
have to remember (or even know) the order in which &KEY arguments appear in the
actual function definition.
(2) This is probably an oversight in the original specification.
Current practice:
Many Common Lisp implementations currently ignore FUNCTION type declarations.
The situation regarding type specifications for keyword arguments is so
ambiguous that few users attempt to use them.
Cost to Implementors:
Implementations that ignore the FUNCTION type specifier or keyword arguments in
a FUNCTION type specifier may continue to do so. This proposal should not
involve massive amounts of code to be rewritten.
Cost to users:
Because the current situation is so ambiguous, FUNCTION type specifiers and
particularly the specification of keyword argument types are not widely used.
However, since this is an incompatible change, it would be nice if
implementations check for, and warn about, old-style usage.
Cost of non-adoption:
If nothing is done, the FUNCTION type specifier will continue to be of limited
use for its intended purpose.
Benefits:
Adopting the proposal will clear up an area of confusion in the language design.
Esthetics:
The syntax is fairly obvious and is analogous to the (<keyword> <variable>)
lambda list syntax.
Discussion:
The exact semantics of function declarations and the types of arguments is
still under discussion, as are several other issues dealing with declarations.
However, this issue seemed separable.
∂14-Feb-88 1231 X3J13-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 12:31:20 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:29:51 PST
Date: 14 Feb 88 12:29 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-122951-1359@Xerox>
This issue is new.
!
Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
References: CLtL p. 27, 47-48, 61
"Artifical Intelligence Programming", Charniak et. al.
X3J13/86-003 (A:>GLS>clarifications.text.4)
Category: CLARIFICATION, ADDITION
Edit history: Version 1, 23-Nov-1987 Sandra Loosemore
Version 2, 15-Jan-1988 Sandra Loosemore
(incorporate comments from Scott Fahlman & others)
Version 3, 13-Feb-88 Masinter
Related issues: FUNCTION-TYPE-KEY-NAME,
FUNCTION-ARGUMENT-TYPE-SEMANTICS
Problem description:
The FUNCTION type specifier list is provided to allow declaration of function
argument types and return value types. This type specifier uses a syntax
similar to the usual lambda list syntax to specify which types go with which
lambda list variables. However, this is actually of limited usefulness in the
context of a declaration, where one normally wants type information about the
actual arguments which can be passed to the function rather than the lambda
variables to which they are bound.
There is a particular problem with &REST lambda variables, which are always
bound to a value of type LIST. For the sake of consistency, it would seem that
the corresponding type given in the FUNCTION declaration must also be LIST, but
since this provides no information about the actual arguments, some
users/implementors have instead adopted the convention of supplying the type of
the actual arguments which are gathered into the list.
CLtL is vague on the issue, mentioning only that &REST may appear in the type
specifier without touching upon its interpretation.
Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE):
Clarify that, in the FUNCTION type specifier, the type specifier provided with
&REST is the type of each actual argument, not the type of the corresponding
lambda variable.
Example:
The type of the function + would be specified as:
(FUNCTION (&REST NUMBER) NUMBER)
Rationale:
This is more useful than specifying that the type of a &REST parameter must be
LIST, since it provides information about the actual arguments.
Current practice:
There does not appear to be any concensus on this issue. Most Common Lisp
implementations currently ignore FUNCTION type declarations. The only examples
found so far are in a text book on Common Lisp, which follows the proposed
syntax.
Cost to Implementors:
Implementations that ignore the FUNCTION type specifier may continue to do so.
Probably only a small amount of code would have to be written/changed in
implementations that currently think that the &REST argument should be LIST.
Cost to Users:
Users who have been using the convention that the &REST type parameter must be
LIST will have to change their code. However, because this issue is so unclear,
the FUNCTION type specifier is probably not used very much.
Cost of non-adoption:
If nothing is done, the FUNCTION type specifier will continue to be of limited
use for its intended purpose.
Benefits:
Adopting the proposal will clear up an area of confusion in the language design.
Esthetics:
Debatable. One the one hand, since the argument type syntax used by the
FUNCTION type specifier mirrors
normal lambda-list syntax, it would be cleaner and less confusing to provide the
type of the lambda variable rather than the type of the actual arguments.
However, considering the types specified in the FUNCTION specifier to be the
types of the actual arguments rather than the types of the parameters as seen on
the receiving end makes the proposed semantics more palatable.
Discussion:
This issue provoked considerable debate in the cleanup committee. There was some
support for an alternative proposal to require that the &REST argument
declaration, if any, always be LIST or a subtype of LIST, and to extend the LIST
type to allow declarations of the form, e.g., (LIST NUMBER).
Those who favor USE-ACTUAL-ARGUMENT-TYPE (including David Moon and Larry
Masinter) argue that the simplicity of the declarations and the ugliness of the
alternative, as well as the weight of current practice, argue for it.
Kent Pitman has argued against this proposal on the following grounds:
``* It is bothersome that the same argument declarations which are used
internally in the function would not be be usable externally.
``* It is unfair to provide only this special-purpose way of declaring a
sequence type when in fact there are numerous other places in the language where
it might be useful to declare a sequence type.
``If we did go with USE-ACTUAL-ARGUMENT-TYPE, it should be stated explicitly (if
it is not already in CLtL somewhere) that the following is illegal:
(DEFUN FOO (&REST X) X)
(APPLY #'FOO T)
since there will be no way to type-declare this. Even though this is an obscure
case (that doesn't even work in some implementations), it's the sort of thing
that makes me queasy about USE-ACTUAL-ARGUMENT-TYPE.''
∂14-Feb-88 1234 @Score.Stanford.EDU:PALLAS@Sushi.Stanford.EDU Re: Accounts on Polya
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Feb 88 12:34:15 PST
Received: from Sushi.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 14 Feb 88 12:27:43-PST
Date: Sun 14 Feb 88 12:27:19-PST
From: Joseph I. Pallas <PALLAS@Sushi.Stanford.EDU>
Subject: Re: Accounts on Polya
To: ARK@Sail.Stanford.EDU
cc: faculty@Score.Stanford.EDU, CSD@Sail.Stanford.EDU
In-Reply-To: Message from "Arthur Keller <ARK@SAIL.Stanford.EDU>" of Sat 13 Feb 88 12:41:00-PST
Message-ID: <12374730945.9.PALLAS@Sushi.Stanford.EDU>
Let us suppose that the Polya costs $P per year. Let us suppose that
Sushi costs $S per year, or that the department is otherwise willing to
pay $S for unsponsored computing.
We should start by being more specific. Let us suppose that Sushi
costs $S per year, and that the department is willing to pay $U for
unsponsored computing.
U < S. This is the crux of the matter. Polya is a red herring, a
diversion, an excuse (but not a reason) to change the department's
financial commitment to student computing. At the time that the
facilities committee was discussing the purchase of Polya, it was
argued that Polya would be more-or-less cost-neutral and
revenue-positive, thus reducing the expense of student computing.
Obviously, it's too early to claim that the expected savings have not
materialized, since there are as yet neither rates nor customers.
If the departmental decision-makers had made their intentions with
respect to student computing clear to the facilities committee,
purchase of Polya would probably NOT have been recommended. Without
student computing, Polya will probably begin the cost-death spiral
immediately, unless a determined effort is made to bring in outside
customers.
The current Navajo customers being shifted to Polya will lose: their
rates will skyrocket, and they will have to go elsewhere (outside of
CSD-CF). CSD-CF will lose, since their newest acquisition will be
cost-dead before it's depreciated. The department, however, will win,
because its share of CSD-CF's loss will be less than what it was
paying for Sushi. That is, CSD is stabbing CSD-CF in the back.
At least, that's how I see it. I'd be interested to hear a rebuttal.
joe
P.S. Thanks to the cost-accounting system, when CSD stabs CSD-CF in
the back, it also stabs CSD-CF's customers -- PIs. So, in reality,
funded research projects are being taxed anyway, only instead of being
taxed to support student computing, they're being taxed to support
CSD-CF to the extent that the department is NOT supporting student
computing. The tax rate is the same, but the money goes down the
drain instead of to some productive end. For some PIs, the tax rate
will be too high: they'll bail out of CSD-CF, reducing the tax base
even further, with the result being even higher rates. Eventually,
CSD-CF as a whole might go into cost-death, since it seems to grow in
size monotonically.
-------
∂14-Feb-88 1300 X3J13-mailer Issue: FUNCTION-TYPE (version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:00:37 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:55:41 PST
Date: 14 Feb 88 12:55 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE (version 9)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
LINE-FOLD: NO
Message-ID: <880214-125541-1381@Xerox>
This is a difficult issue. The issue was discussed both at the June and November 1987 meetings. There seem to be strong opinions along several different dimensions.
This version of the issue writeup contains two different proposals.
!
Issue: FUNCTION-TYPE
References: functions (p32), types (p33), FUNCTIONP (p76),
SYMBOL-FUNCTION (p90), APPLY (p107), COERCE (pp51-52)
Category: CHANGE
Edit History: 26-Feb-87, Version 1 by Gabriel
15-Mar-87, Version 2 by Cleanup Committee
10-May-87, Version 3 by Fahlman
29-May-87, Version 4 by Masinter (incorporate comments)
15-Jun-87, Version 5 by Fahlman (include two options)
23-Oct-87, Version 6 by Masinter (only STRICT-REDEFINITION)
09-Nov-87, Version 7 by Masinter (minor cleanup)
14-Nov-87, Version 8 by Pitman (major restructuring)
13-Feb-88, Version 9 by Masinter, (add back 2nd option)
Problem Description:
The definition of the term ``function'' in CLtL includes all symbols and
many lists in addition to `true' functions.
Also, page 47 of CLtL states that the FUNCTION type specifier can only
be used for declaration and not for discrimination. Some of the original
Common Lisp designers maintain that this restriction on the use of the
FUNCTION specifier was meant to apply only to long-form FUNCTION
specifiers, but since this intent was not explicitly stated, the status
of FUNCTION as a type is blurred.
A consequence of the p47 confusion is that (FUNCTIONP x) cannot portably
be relied upon to be equivalent to (TYPEP x 'FUNCTION).
There are two proposals for dealing with this issue.
!
Proposal FUNCTION-TYPE:CONSERVATIVE
1. Introduce a new type PROCEDURE that can be used both for declaration
and discrimination.
1a. The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and PROCEDURE
are pairwise disjoint. In particular, a list may not be used
to implement any PROCEDURE subtype.
1b. Define that the type COMPILED-FUNCTION is a subtype of PROCEDURE.
Implementations are free to define other subtypes of PROCEDURE.
1c. Introduce a new function, PROCEDUREP, such that
(PROCEDUREP x) == (TYPEP x 'PROCEDURE).
2. Define that a ``function'' may be a procedure, a list whose car is
the symbol LAMBDA, or any symbol (whether fbound or not).
2a. Clarify that the FUNCTION type behaves as if it had been
defined by:
(DEFUN LAMBDA-P (X) (AND (NOT (ATOM X)) (EQ (CAR X) 'LAMBDA)))
(DEFTYPE FUNCTION ()
`(OR SYMBOL (SATISFIES LAMBDA-P) PROCEDURE))
2b. Clarify that (FUNCTIONP x) == (TYPEP x 'FUNCTION).
This change is compatible.
2c. Clarify that the list form of the FUNCTION type specifier may
still only be used for declaration.
2d. Clarify that the symbol form of the FUNCTION type specifier may
be used for type discrimination.
2e. Clarify that FUNCALL and APPLY continue to accept functions
as arguments. However, some implementations may produce better
code for expressions such as (FUNCALL (THE PROCEDURE ...) ...)
or (APPLY (THE PROCEDURE ...) ...).
3. Clarify that the result of a FUNCTION special form must be a procedure.
3a. This implies that some (FUNCTION name) may be implicitly interpreted
as (THE PROCEDURE (FUNCTION name)). As such, the potential
optimizations mentioned in 2e are also possible for
(FUNCALL (FUNCTION ...) ...) and (APPLY (FUNCTION ...) ...).
4. Clarify that it is an error to use the special form FUNCTION on a
symbol that does not denote a function in the lexical environment in
which the special form appears. Specifically, it is an error to use the
FUNCTION special form on a symbol that denotes a macro or special form.
4a. Some implementations may choose not to signal this error for
performance reasons, but implementations are forbidden from
defining the failure to signal an error as a `useful' behavior.
5. Clarify that it is permissible for FBOUNDP to return true for a macro
or special form, and that it is permissible to call SYMBOL-FUNCTION
on any symbol for which FBOUNDP returns true.
5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
but the symbol denotes a macro or special form is not well-defined,
but SYMBOL-FUNCTION will not signal an error.
5b. Assuming that symbol is fbound,
(PROCEDUREP (SYMBOL-FUNCTION symbol))
implies
(AND (NOT (MACRO-FUNCTION symbol))
(NOT (SPECIAL-FORM-P symbol))).
5c. The effect of
(SETF (SYMBOL-FUNCTION symbol) non-procedure)
is not defined. Implementations are permitted to signal an error,
but they are also permitted to define useful (non-portable)
interpretations.
5d. The motivation for this distinction between FUNCTION and
SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day
use within programs while SYMBOL-FUNCTION is a data structure
accessor used primarily for meta-level applications and not
recommended for general use. It is provided primarily to
complete the set of accessors on symbols.
Implementations are permitted, but not required, to store
information about a global macro-function or special form
in the function cell. This definition of SYMBOL-FUNCTION
is intended to leave enough freedom for such implementations
to conveniently implement FUNCTION, SPECIAL-FORM-P, and
MACRO-FUNCTION using SYMBOL-FUNCTION as the underlying
subprimitive.
6. COERCE is extended to allow objects to be coerced to type procedure.
6a. (COERCE symbol 'PROCEDURE) extracts the symbol-function of the
given symbol, signalling an error if SYMBOL is not fbound or if
the contents of the symbol-function cell is not a procedure.
6b. (COERCE lambda-expression 'PROCEDURE) is equivalent to
(EVAL `(FUNCTION ,lambda-expression)).
7. Clarify *MACROEXPAND-HOOK* is permitted to contain any kind of function.
The function is coerced to a procedure before being called as the
expansion interface hook by MACROEXPAND-1.
!
Proposal FUNCTION-TYPE:STRICT-REDEFINITION
STRICT-REDEFINITION is similar to CONSERVATIVE, except that it redefines
the type FUNCTION instead of adding a new type PROCEDURE, and it restricts
coercion by functions that take functions as arguments. The numbering of
CONSERVATIVE is preserved for comparison.
1. Redefine the type FUNCTION so that it can be used for discrimination
as well as declaration.
1a. The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION
are pairwise disjoint. In particular, a list may not be used
to implement any PROCEDURE subtype.
1b. Define that the type COMPILED-FUNCTION is a subtype of FUNCTION.
Implementations are free to define other subtypes of FUNCTION.
2. Define that a ``function'' as used throughout the CLtL is restricted
to be exactly those objects of type FUNCTION.
2a. This type no longer includes objects of type SYMBOL or lists
with CAR = LAMBDA.
2b. The behavior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). This is an incompatible
change.
2c. Clarify that the list form of the FUNCTION type specifier may
still only be used for declaration.
2d. Clarify that the symbol form of the FUNCTION type specifier may
be used for type discrimination.
2e. Change FUNCALL and APPLY such that they accept only a function
as the functional argument. This restriction is inherited by
all functions in Common Lispthat take a functional argument.
It is no longer legal to pass a symbol or lambda expression as
the functional argument to any of these functions; to do so
"is an error".
3. Clarify that the result of a FUNCTION special form must be a function.
3a. This implies that some (FUNCTION name) may be implicitly interpreted
as (THE FUNCTION (FUNCTION name)).
4. Clarify that it is an error to use the special form FUNCTION on a
symbol that does not denote a function in the lexical environment in
which the special form appears. Specifically, it is an error to use the
FUNCTION special form on a symbol that denotes a macro or special form.
4a. Some implementations may choose not to signal this error for
performance reasons, but implementations are forbidden from
defining the failure to signal an error as a `useful' behavior.
5. Clarify that it is permissible for FBOUNDP to return true for a macro
or special form, and that it is permissible to call SYMBOL-FUNCTION
on any symbol for which FBOUNDP returns true.
5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
but the symbol denotes a macro or special form is not well-defined,
but SYMBOL-FUNCTION will not signal an error.
5b. Assuming that symbol is fbound,
(FUNCTIONP (SYMBOL-FUNCTION symbol))
implies
(AND (NOT (MACRO-FUNCTION symbol))
(NOT (SPECIAL-FORM-P symbol))).
5c. The effect of
(SETF (SYMBOL-FUNCTION symbol) non-procedure)
is not defined. Implementations are permitted to signal an error.
5d. The motivation for this distinction between FUNCTION and
SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day
use within programs while SYMBOL-FUNCTION is a data structure
accessor used primarily for meta-level applications and not
recommended for general use. It is provided primarily to
complete the set of accessors on symbols.
6. COERCE is extended to allow objects to be coerced to type procedure.
6a. (COERCE symbol 'FUNCTION) extracts the symbol-function of the
given symbol, signalling an error if SYMBOL is not fbound or if
the contents of the symbol-function cell is not a procedure.
6b. (COERCE lambda-expression 'FUNCTION) is equivalent to
(EVAL `(FUNCTION ,lambda-expression)).
7. Clarify that the value of *MACROEXPAND-HOOK* is first coerced to a
function before being called as the
expansion interface hook by MACROEXPAND-1.
!
Rationale:
Since the two proposals are similar, they are discussed together. Where
motiviation and justification differ, the proposals are referred to by
name (STRICT-REDEFINITION, CONSERVATIVE.)
The fuzzy definition of ``function'' has descended from older dialects of
Lisp, such as Maclisp. Many places in existing code make assumptions about
the current meaning, making any change painful.
It is very important both for documentation clarity and for program type
discrimination (such as CLOS) to have a clear term which denotes a
``true function.''
CONSERVATIVE manages a compatible definition with most existing uses of
the term ``function'' while providing a graceful upgrade path to the term
``procedure'' for use in situations that call for a higher degree of clarity.
STRICT-REDEFINITION avoids introducing a new term at the cost of
incompatible change.
Current Practice:
In some implementations, (TYPEP x 'FUNCTION) signals an error.
In some implementations, (TYPEP x 'FUNCTION) is the same as (FUNCTIONP x).
In some implementations, (TYPEP x 'FUNCTION) is the same as what
CONSERVATIVE calls (TYPEP x 'PROCEDURE).
Implementations vary on what my go into the function cell, depending on
how much error checking they want to have to do at function call time, and
depending on whether they store other kinds of information (such as special
form information) in the function cell.
Few current Common Lisp implementations are likely to have exactly the
semantics described in either. CONSERVATIVE is more compatible with
current practice than STRICT-REDEFINITION, however.
Cost to Implementors:
Bringing type predicates (FUNCTIONP, etc.) and higher order functions
(APPLY, etc.) into compliance should require little effort in most
implementations. While STRICT-REDEFINITION makes it an error to pass
non-function arguments to APPLY, FUNCALL etc, there is no requirement
to check for that error.
Compiled functions are true functions in almost all current
implementations, but in many implementations, interpreted functions and
closures stored in the function cell of a symbol are represented as lists.
Under this proposal, this representation would have to be different
(implemented either as structures or to some special internal data type).
The behavior of COMPILE, STEP, TRACE, and possibly ED would have to be
modified to deal with functions that are not lists (but from which the
list form can be reconstructed if necessary).
Cost to Users:
The conversion cost associated with CONSERVATIVE is very low because the
model of FUNCTIONP which it takes is largely consistent with existing
practice.
The new features introduced by CONSERVATIVE, particularly the PROCEDURE
data type, can be converted to fairly lazily.
The conversion cost for the STRICT-REDEFINITION proposal is higher. The
changes to FUNCTIONP and the FUNCTION type declaration is relatively easy
to deal with. However, the strict redefinition of FUNCALL, APPLY and
functional arguments will require the addition of an explicit coercion
would have to be added whenever a symbol or lambda expression is used as
a functional argument. Many such cases can be identified at compile time,
but not all.
Some implementations might provide tools to assist in detecting implicit
coercion of symbols to functions. For example, an implementation might add
run-time test in which the implementation still does the coercion but that
issues a warning message whenever the coercion is actually needed.
Alternatively, a "smart" code-walker or editor macro might find all of the
calls to FUNCALL, APPLY, and the 61 Common Lisp functions that take :TEST
or :KEY arguments and, if the argument is not already an explicitly quoted
FUNCTION form, wrap a COERCE around the body.
For either proposal:
Because CLtL's language was somewhat fuzzy about what might go into the
function cell of a symbol, some code that explicitly deposited symbols
or lists in a symbol's function cell might have to change. Such code was
already not portable, however, since some implementations signal an error
when this is done.
Benefits:
For CONSERVATIVE:
The term ``function'' would be given a useful meaning that was relatively
compatible with existing usage.
A new term ``procedure'' would be available for descriptional clarity.
The new PROCEDURE datatype would be useful for type discrimination in CLOS.
For STRICT-REDEFINITION:
The term ``function'' would be given a useful and precise meaning.
The FUNCTION datatype would be useful for type discrimination in CLOS.
STRICT-REDEFINITION provides useful constraints which will be of aid
to systems doing automatic program analysis for the purpose of
``selective linking.'' Such tools may in turn make it possible to
reduce the total size of a delivered application program because
only those Common Lisp functions that are actually called need to be
included.
For either proposal:
The type hierarchy would be simplified.
Either proposal brings Common Lisp into closer alignment with Scheme and
the work of the EuLisp committee. Scheme, for example, also has the concept
of a ``procedure'' which is compatible with this proposal.
Aesthetics:
Both proposals improve the aesthetics of the language.
Discussion:
These proposals have been discussed at great length; this section attempts
only to summarize the important points.
There is general agreement that the definition of the FUNCTION data type
must be clarified or revised. The cleanup of the type hierarchy is important
to the CLOS group.
The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". We believe this is a subject for a separate
proposal, as the behavior of COMPILE needs additional clarification.
Many different alternatives have been discussed both in the cleanup committee
and X3J13. These two proposals are the distillation of the alternatives.
The CONSERVATIVE proposal offers the advantage of backward compatibility,
and considerably more flexibility in the language.
The STRICT-REDEFINITION proposal offers the advantage of a slightly cleaner
resulting language.
Some concerns were raised about STRICT-REDEFINITION in a previous discussion
about "late binding" of function definitions. Neither proposal disallows
late binding of symbols to functions. For example, in the call
(MAPCAR #'FROB my-list)
the effect of the FUNCTION special form (as generated by the #' read macro)
is to obtain the function definition of FROB at the time the #'FROB is
evaluated. Neither proposal changes this.
Currently, it is allowed to write
(MAPCAR 'FROB my-list)
while this form would no longer be allowed under the STRICT-REDEFINITION
clause. Currently, neither CLtL nor the CONSERVATIVE proposal addresses
the question of the time at which FROB's function definition is obtained;
if, during the processing of my-list, FROB is redefined, it is not clear
whether the processing of subsequent elements would be changed.
∂14-Feb-88 1301 X3J13-mailer Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:00:57 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:58:56 PST
Date: 14 Feb 88 12:58 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-125856-1384@Xerox>
This issue passed conditionally at the June 1987 meeting; this revision was
distributed at the November 1987 meeting.
!
Issue: GET-SETF-METHOD-ENVIRONMENT
References: GET-SETF-METHOD (CLtL p 187)
Category: Change
Edit History: Version 1 9-Jan-87, Version 1 by Masinter
(no version) 7-Apr-87, merged with ENVIRONMENT-ARGUMENTS
Version 2 29-May-87, extracted again
Version 3 5-Jun-87, by Masinter
Version 4 11-Jun-87, for release
Version 5 13-Jul-87, by Masinter
Problem Description:
If a macro that performs similar processing to SETF uses GET-SETF-METHOD, and
that macro occurs within a MACROLET, the expansion will not see the MACROLET
definition, e.g.,
(defmacro special-incf ... (get-setf-method ...) ...)
then
(macrolet ((test (x) `(car ,x)))
(special-incf (test z)))
would not "see" the test definition.
Proposal (GET-SETF-METHOD-ENVIRONMENT:ADD-ARG):
Add an optional environment argument to GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE. If the argument is not supplied, it defaults to
the null lexical environment. NIL can also be passed explicitly to denote the
null lexical environment.
Allow &ENVIRONMENT variable to appear in the lambda-list subform of a
DEFINE-SETF-METHOD form, as with a DEFMACRO.
Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the environment
to GET-SETF-METHOD.
Clarify that, within the scope of a MACROLET, FLET and LABELS, global SETF
definitions of the name defined by the MACROLET, FLET or LABELS do not apply. A
SETF method applies only when the global function binding of the name is
lexically visible. All of the built in macros of Common Lisp (SETF, INCF, DECF,
POP, ROTATEF, etc.) which modify location specifications obey this convention.
Test Case:
;;; This macro is like POP
(defmacro xpop (place &environment env)
(multiple-value-bind (dummies vals new setter getter)
(get-setf-method place env)
`(let* (,@(mapcar #'list dummies vals) (,(car new) ,getter))
(prog1 (car ,(car new))
(setq ,(car new) (cdr ,(car new)))
,setter)))))
(defsetf frob (x) (value)
`(setf (car ,x) ,value))
;;; The following will modify (cdr z) and not (car z)
(macrolet ((frob (x) `(cdr ,x)))
(xpop (frob z)))
;;; The following is an error; an error may be signaled at macro expansion time
(flet ((frob (x) (cdr x))
(xpop (frob z)))
Rationale:
This was an omission in the original definition of CLtL.
Current Practice:
Many Common Lisp implementations already have this extension, although some do
not. One implementation has extended GET-SETF-METHOD to take an optional
argument which is incompatible with this use.
Cost to implementors:
Some implementations will have to add this feature, although it is not a major
change.
Cost to users:
This is generally an upward compatible change. In implementations which did not
already take into account the lexical environment for SETF'd forms might start
working differently if the internal implementation of SETF is changed. The
likelihood of this affecting a user's program is very small.
Benefits:
This change improves portability and the ability to use MACROLET, FLET and
LABELS in portable code which might also have SETF forms.
Aesthetics:
SETF methods cannot work correctly within lexically defined function symbols
without this change. This change makes the language more consistent and correct.
Discussion:
The cleanup committee generally supports this change.
A number of additional changes for rationally dealing with lexical environments
as first class objects, including a more general set of accessors and
constructors for lexical environments is required for many language extensions
(e.g., a portable version of the proposed Common Lisp Object System) and should
be addressed by a future proposal. For a while, the cleanup committee attempted
to deal with these issues together, but decided to separate them out into their
component parts. This issue is the simplest.
∂14-Feb-88 1306 X3J13-mailer Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:06:45 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:07:20 PST
Date: 14 Feb 88 13:06 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-130720-1391@Xerox>
Version 6 conditionally passed X3J13/Jun87. Version 8 distributed in hardcopy
form X3J13/Nov87.
!
Issue: KEYWORD-ARGUMENT-NAME-PACKAGE
References: Lambda Expressions (CLtL pp60-64)
Category: CLARIFICATION/CHANGE
Edit history: 20-Apr-87, Version 1 by Moon
29-Apr-87, Version 2 by Pitman
11-May-87, Version 3 by Moon
29-May-87, Version 4 by Masinter
5-Jun-87, Version 5 by Masinter
11-Jun-87, Version 6 by Masinter
23-Oct-87, Version 7 by Masinter
8-Nov-87, Version 8 by Moon
Problem Description:
CLtL says that only keyword symbols can be used as keyword-names in
&key parameter specifiers (page 60, "each -keyword- must be a
keyword symbol, such as :start.")
As Common Lisp is currently defined, if someone wants to define a
function that accepts keyword (rather than positional) arguments whose
keyword-names are symbols in packages other than the KEYWORD package,
they cannot use &KEY. Instead, they have to duplicate the &KEY mechanism
using &REST, GETF, and (if they want error checking of argument names)
DO.
Some applications (including the draft proposal for the Common Lisp
Object System (CLOS)) require this capability. [See Rationale below.]
Proposal (KEYWORD-ARGUMENT-NAME-PACKAGE:ANY)
Remove restrictions on the package of the keyword-names of keyword
parameters; allow any symbol. That is:
If, following an &KEY, a variable appears alone or in a (variable
default-value) pair, the behavior specified in CLtL is unchanged: a
keyword symbol with the same print name as the variable is created and
is used as the keyword-name when matching arguments to parameter
specifiers. A keyword-name that is not a keyword symbol can be
specified with the ((-keyword- -var-) ...) syntax of parameter
specifier. The -keyword- can be any symbol, not just a keyword.
A future specification of Common Lisp could be written with revised
terminology that did not use the term "keyword" to refer to three
different things: symbols in the KEYWORD package, symbols beginning
with & that have special meaning in lambda-lists, and keyword-names
used to match function arguments to keyword parameter specifiers.
However, this proposal does not propose to change any terminology.
Test case:
(DEFUN RESULT (&KEY ((SECRET-KEYWORD SECRET) NIL) AMOUNT)
(FORMAT NIL "You ~A $~D" (if SECRET "win" "lose") AMOUNT))
(RESULT :AMOUNT 100) => "You lose $100"
(RESULT :AMOUNT 100 'SECRET-KEYWORD T) => "You win $100"
Rationale:
The "rationale" box on p.62 of CLtL is an argument in favor of requiring
keyword-names to be symbols, and disallowing numbers, but does not
speak to the issue of whether or not those symbols should be further
restricted to be in the KEYWORD package.
The desire for keyword parameters whose keyword-names are not in the
KEYWORD package arises when the set of keyword-names accepted by a
function is the union of the sets of keyword-names accepted by several
other functions, rather than being enumerated in a single place. In
this case, it becomes desirable to use packages to prevent accidental
name clashes among keyword-names of different functions.
One example of a Common Lisp application that requires this capability
is the draft proposal for an object-oriented programming standard
(CLOS). It will have generic functions that accept arguments and pass
them on to one or more applicable methods, with each method defining its
own set of keyword-names that it is interested in. If this proposal is
not adopted, either the keyword-names will be required to be keywords,
which will require the methods to have non-modular knowledge of each
other in order to avoid name clashes, or the methods will have to be
defined with an ad hoc mechanism that duplicates the essential
functionality of &key but removes the restriction.
A second example of a Common Lisp application that requires this
capability is private communication channels between functions. Suppose
a public routine MAKE-FOO needs to accept arbitrary arguments from the
caller and passes those arguments along to an internal routine with
additional arguments of its own, and suppose that keyword parameters
are used to receive these arguments.
(IN-PACKAGE 'FOOLAND)
(DEFUN MAKE-FOO (&REST NAME-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
(APPLY #'MAKE-FOO-INTERNAL 'EXPLICIT T NAME-VALUE-PAIRS))
This could be done without fear that the use of EXPLICIT T would
override some argument in NAME-VALUE-PAIRS, since the only way
that could happen is if someone had done (MAKE-FOO 'FOOLAND::EXPLICIT
NIL), or if the user was programming explicitly in the FOOLAND package,
either of which is an implicit admission of willingness to violate
FOOLAND's modularity.
Documentation Impact:
Some careful rewording of the existing language in CLtL is necessary in
the standard to avoid confusion between "keyword", indicating a symbol
in the KEYWORD package, and "keyword name", indicating a syntactic part
of a keyword parameter specifier. It is likely that this is best served
by changing those instances of "keyword" to "named argument" when the
specification is discussing the indicator which introduces an actual
parameter in a call to a function defined with &KEY.
The wording which refers to named arguments as being introduced by
keyword symbols would change to simply refer to those arguments being
introduced by symbols. For example, in the middle of p.60, the sentence:
... each -keyword- must be a keyword symbol, such as :start.
would become
... each named argument name must be a symbol.
The word "keyword" in the first complete sentence on p.62 would be
changed to "symbol" for similar reasons.
Extra wording would have to be added on p.60 to explain that by
convention keyword symbols are normally used as the names for named
arguments, and that all functions built into the Common Lisp language
follow that convention.
Examples would be useful. On p.64 the following examples might be added:
((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6)
=> (1 2 6 NIL)
((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6)
=> (1 2 6 NIL)
Current Practice:
We do not currently know of an implementation that enforces the
restriction that this proposal seeks to remove.
Some implementations have bugs that prevent NIL from working as a
keyword argument name, but allow all non-NIL symbols. (One Symbolics
version that was checked had this bug.)
Cost to implementors:
Some implementors might have to rearrange their error checking slightly,
but it should be very easy.
Cost to users:
None--no existing programs will stop working.
Benefits:
This will help with the object-oriented programming standard, among
other things.
Aesthetics:
The restriction of &key to only keyword symbols is arbitrary and
unnecessary.
There will probably be an argument about whether the restriction is more
aesthetic or less aesthetic than the freedom, but in either case the
aesthetic effect is slight.
In any case, users who do not want to use the extended functionality can
generally avoid it.
Discussion:
The cleanup committee generally supports this extension.
Moon was under the impression that this proposal was actually adopted
around December 1985 (although no formal mechanism for adopting
proposals existed at that time), but may be mistaken.
If Common Lisp truly has a restriction that only keyword symbols can be
used as keyword names in calls to functions that take keyword arguments,
it will be more difficult to come up with an object-oriented programming
standard that fits within Common Lisp.
The cleanup committee considered, but did not adopt, a proposal to
exclude NIL as a legal indicator. It might catch some errors, but is
otherwise an odd restriction.
∂14-Feb-88 1310 X3J13-mailer Issue: PATHNAME-STREAM (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:10:14 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:10:49 PST
Date: 14 Feb 88 13:10 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-STREAM (Version 6)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-131049-1395@Xerox>
Version 2 conditionally passed X3J13/Jun87. Version 6 was distributed in
hardcopy form X3J13/Nov87.
!
Issue: PATHNAME-STREAM
References: PATHNAME (p.413), also the introductory text right above
it on the same page.
Derived references: TRUENAME (p.413), PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
OPEN (p.418), WITH-OPEN-FILE (p.422),
RENAME-FILE (p.423), DELETE-FILE (p.424)
Edit History: Version 1 by Moon 11-May-87
Version 2 by Masinter 29-May-87 (minor editing)
Version 3 by Masinter 11-Jun-87 (minor editing)
Version 4 by Masinter 8-Oct-87 (rewording)
Version 5 by Masinter 8-Oct-87 (explicitly only open)
Version 6 by Masinter 14-Nov-87
Category: CHANGE/CLARIFICATION
Problem Description:
CLtL says that a stream can be used as an argument and converted to a pathname,
but many sources or sinks of data that streams might be connected to have no
pathnames associated with them; for example, streams created with
MAKE-TWO-WAY-STREAM or OPEN-STRING-STREAM. For many such streams, there is no
simple way to coerce such a stream to a pathname.
Proposal PATHNAME-STREAM:FILES-OR-SYNONYM:
Clarify that the use of a stream as an argument that expects a pathname (as
described on p413 of CLtL) only applies to streams that are originally opened by
use of the OPEN or WITH-OPEN-FILE, or to synonym streams whose symbol is bound
to such a stream. It is an error to attempt to obtain a pathname from a stream
created with MAKE-TWO-WAY-STREAM, OPEN-STRING-STREAM, MAKE-ECHO-STREAM,
MAKE-BROADCAST-STREAM, MAKE-CONCATENATED-STREAM, MAKE-STRING-INPUT-STREAM,
MAKE-STRING-OUTPUT-STREAM.
The pathname used represents the name used to open the file. This may be, but is
not required to be, the actual name of the file. The pathname used is the same
as would be returned by the PATHNAME function.
Rationale:
This is probably what the designers of Common Lisp intended. This is the only
thing that can be implemented without large changes to the language such as
extending pathnames to things other than files.
Current Practice:
Some systems signal an error if a non-file stream is used as a pathname. Others
return an empty pathname.
Some implementations do not return a meaningful value for PATHNAME of a synonym
stream.
Adoption Cost:
Implementations that do not currently handle PATHNAME of a synonym stream will
have to change to allow it. Otherwise, since the proposal says only "is an
error" rather than "signals an error", no implementations other changes are
necessary.
Benefits:
The description of pathname functions will make more sense.
Conversion Cost:
Small: Users with code which accesses pathname components of streams in
implementations which allow it might need to change their programs to make them
portable.
Aesthetics:
Makes language a little cleaner.
Discussion:
The only point of disagreement on this proposal has been on the issue of whether
PATHNAME applies to synonym streams and returns the pathname of the stream
designated.
This version of the proposal says yes, because CLtL p 329 says about synonym
streams that "Any operations on the new stream ..." and does not say anything
about exceptions; earlier on the page the phrase "synonym streams that pass all
operations on" is used. This seems fairly unambiguous, although the word
"operations" is not defined. There was a similar controversy about what CLOSE of
a synonym stream means.
Note that there is currently no way portable to determine whether a stream has a
pathname available.
The entire PATHNAME section needs work to clarify the intent and enable portable
code. This is just a minor issue among the major ones.
∂14-Feb-88 1328 X3J13-mailer Issue: PATHNAME-SYMBOL (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:28:34 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:26:37 PST
Date: 14 Feb 88 13:26 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-SYMBOL (Version 5)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-132637-1426@Xerox>
My notes are unclear. This issue may have been distributed before.
!
Issue: PATHNAME-SYMBOL
References: PATHNAME (p.413),
Derived references: PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
NAMESTRING etc. (p.417), LOAD (p. 426), REQUIRE
Cleanup issue PATHNAME-STREAM
Common LispCraft, Wilensky 1986, p 51
Edit History: Version 1 by Moon 11-May-87
Version 2 by Masinter 29-May-87
Version 3 by Masinter 23-Oct-87
Version 4 by Masinter 23-Nov-87
Version 5 by Masinter 5-Feb-88, fix minor typo
Category: CHANGE
Problem Description:
Some Common Lisp functions are specified to accept a symbol where a pathname is
expected. Some others (OPEN, WITH-OPEN-FILE, DELETE-FILE, and RENAME-FILE) are
not specified to accept a symbol.
Proposal PATHNAME-SYMBOL:NO
Never allow symbols where pathnames are expected. More specifically, PATHNAME,
TRUENAME, PARSE-NAMESTRING, MERGE-PATHNAMES, PATHNAME-HOST, PATHNAME-DEVICE,
PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION, NAMESTRING,
FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING, ENOUGH-NAMESTRING,
REQUIRE are changed by this proposal to not allow symbols for their pathname
argument.
Reiterate that OPEN, WITH-OPEN-FILE, LOAD, COMPILE-FILE, RENAME-FILE,
DELETE-FILE, FILE-WRITE-DATE, FILE-AUTHOR do not allow symbols for their file or
filename argument, and that DIRECTORY does not allow a symbol for its pathname
argument. This is implied by the respective descriptions of those functions in
CLtL, but not explicitly stated.
Rationale:
Allowing symbols for pathnames was based on an obsolete practice in MacLisp
(which did not have strings) and causes much error-prone behavior.
Current Practice:
Varies. Some implementations allow symbols here, some don't. Symbolics doesn't
allow symbols except in PARSE-NAMESTRING and MERGE-PATHNAMES, and allowing them
there is probably a bug in the implementation.
Cost to implementors:
It's easy to change implementations to stop accepting symbols. Since this
appears to be an "is an error" rather than "signals an error" situation, no
implementation change is actually necessary.
Cost to users:
Some users might be using symbols as pathnames, in implementations where that
works, and they would have to switch to using strings. For example, some users
are used to typing interactively (LOAD 'FOO) to mean (LOAD "FOO"). This is not
explicitly allowed in CLtL, so such behavior has not been portable. However,
such use is probably widespread among users of implementations that allow it
(e.g., Common LISPCraft gives this form in an example.)
Benefits:
Pathname functions will be more consistent. In implementations that check the
type of this argument, program error checking will be improved. In dealing with
case-sensitive file systems, users won't do (load 'foo) and wonder why file
"FOO" (rather than "foo") is not found.
One example of the type of bug caused by this occurs when NIL is erroneously
substituted for a pathname, perhaps because GETHASH or ASSOC didn't find a table
entry that was expected to exist and returned -false-. In systems that accept
symbols as pathnames, this causes a reference to a file named "NIL" on some
perhaps unexpected directory.
Aesthetics:
Improved by the change.
Discussion:
Some users have reported that they thought MERGE-PATHNAMES was in error because
it accepted symbols.
We believe that this feature was accidentally introduced as a historical
artifact and that it has limited utility. It is likely that the feature of
accepting a symbol was copied by Common Lisp from Zetalisp, which in turn copied
it from Maclisp. The reason Maclisp allowed a symbol here was that it did not
have strings at all. While the feature was removed from Zetalisp before Common
Lisp was defined due to the poor state of Zetalisp documentation at the time the
change was overlooked by the designers of Common Lisp.
If a symbol can be coerced into a string, and a string can be coerced into a
pathname, why can't a symbol be coerced into a pathname? An explicit decision
was made early in the design of CL not to make all coercions transitive. For
example, symbols coerce to strings (for string functions), and strings are
sequences (and so can be mixed with other sequence types), but symbols are not
sequences.
There is some sentiment for extending COERCE to allow explicit coersion of
STRINGs to PATHNAMEs, as a separate cleanup item.
A careful reading of CLtL indicates that it is possible for an implementation to
allow a symbol to be a STREAM (there is no requirement that STREAM and SYMBOL be
disjoint.) While there is some sentiment for making this requirement in a
separate cleanup issue, it would otherwise prevent both symbol->pathname and
stream->pathname to have consistent meaning.
∂14-Feb-88 1338 X3J13-mailer Issue: PUSH-EVALUATION-ORDER (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:38:15 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:37:53 PST
Date: 14 Feb 88 13:37 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: PUSH-EVALUATION-ORDER (Version 5)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-133753-1430@Xerox>
I believe this issue was not distributed before.
!
Issue: PUSH-EVALUATION-ORDER
References: CLtL p. 99 (generalized variables)
p. 270 (PUSH)
All macros that manipulate generalized variables
(SETF, PSETF, GETF, REMF, INCF, DECF, PUSH, PUSHNEW,
POP, CHECK-TYPE, ASSERT, CTYPECASE, CCASE, SHIFTF,
ROTATEF, and all macros defined by DEFINE-MODIFY-MACRO).
Issue SETF-FUNCTION-VS-MACRO.
Category: CLARIFICATION
Edit History: Version 1, 15-Oct-87, Jeff Peck
Version 2, 23-Oct-87, Larry Masinter
Version 3, 8-Nov-87, David Moon
Version 4, 14-Nov-87, Larry Masinter
Version 5, 25-Nov-87, Larry Masinter
Problem Description:
In the form (PUSH (ref1) (CAR (ref2))) It is unclear whether (ref1) should be
evaluated before (ref2).
CLtL, page 99, in a discussion of generalized variable macros, states:
"Macros that manipulate generalized variables must guarantee the `obvious'
semantics: subforms of generalized-variable references are evaluated ... in
exactly the same order as they appear in the *source* program. The expansion of
these macros must consist of code that follows these rules or has the same
effect as such code. This is accomplished by introducing temporary variables
bound to the subforms of the reference."
This paragraph and a discussion of SETF on the previous pages may also be
interpreted as requiring that *all* subforms of such macro calls should be
evaluated once, in source order, left to right.
However, CLtL, page 270 states:
"The effect of (PUSH Item Place) is roughly equivalent to
(SETF Place (CONS Item Place))
except that the latter would evaluate any subforms of Place twice while PUSH
takes care to evaluate them only once."
Place and Item appear in different order in the PUSH form and the indicated
equivalent SETF form. Should the PUSH form have primacy over the obvious SETF
form with respect to the left-to-right evaluation?
Are all subforms in a macro call guaranteed to be evaluated in order, or only
those subforms representing generalized variable references?
The same question arises for other forms which manipulate generalized variables,
e.g., PUSHNEW, INCF, DECF, and those defined with DEFINE-MODIFY-MACRO.
Proposal: PUSH-EVALUATION-ORDER:ITEM-FIRST
This proposal is hard to state, although the intent is fairly clear: evalution
proceeds from left to right whenever possible. The left-to-right rule does not
remove the obligation on writers of macros and define-setf-method to ensure
left-to-right order, however.
In this proposal, a form is something whose syntactic use is such that it will
be evaluated. A "subform" means a form that is nested inside another form -- not
any object nested inside a form regardless of syntactic context.
(1) The evaluation ordering of subforms within a generalized variable reference
is determined by the order specified by the second value returned by
GET-SETF-METHOD. For all predefined generalized variable references (GETF, LDB),
this order of evaluation is exactly left-to-right. When a generalized variable
reference is derived from a macro expansion, this rule is applied *after* the
macro is expanded to find the appropriate generalized variable reference.
This is intended to make it clear that if the user writes a DEFMACRO or
DEFINE-SETF-METHOD that doesn't preserve order, the the order specified in the
user's code holds; e.g., given
(DEFMACRO WRONG-ORDER (X Y) `(GETF ,Y ,X))
that (PUSH <value> (WRONG-ORDER <place1> <place2>)).
will evaluate <place2> first and then <place1> because that is the order they
are evaluated in the macro expansion.
(2) For the macros that manipulate generalized variables (PUSH, PUSHNEW, GETF,
REMF, INCF, DECF, SHIFTF, ROTATEF, PSETF, SETF, POP, and those defined with
DEFINE-MODIFY-MACRO) the subforms of the macro call are evaluated exactly once
in left to right order, with the subforms of the generalized variable references
evaluted in the order specified in (1).
PUSH, PUSHNEW, GETF, REMF, INCF, DECF, SHIFTF, ROTATEF, PSETF, POP evaluate all
subforms before modifying any of the generalized variable locations. SETF (in
the case when the SETF macro has more than two arguments) performs its operation
on each pair in sequence, i.e., in (SETF <place1> <value1> <place2> <value2>
...), the subforms of <place1> and <value1> are evaluated, the location
specified by <place1> is modified to contain the value returned by <value1>, and
then the rest of the SETF form is processed in a like manner.
(3) For the macros CHECK-TYPE, CTYPECASE, and CCASE, subforms of the generalized
variable reference are evaluted once as in (1), but may be evaluted again if the
type check files in the case of CHECK-TYPE or none of the cases hold in
CTYPECASE and CCASE.
(4) For the macro ASSERT, the order of evaluation of the generalized variable
references is not specified.
(Rules 2, 3 and 4 cover all macros defined in Common Lisp that manupulate
generalized variable references.)
Examples:
(LET ((REF2 (LIST '())))
(PUSH (PROGN (PRINC "1") 'REF-1)
(CAR (PROGN (PRINC "2") REF2))))
Under this proposal, this would be required to print 12 and not 21.
(LET (X)
(PUSH (SETQ X (LIST 'A))
(CAR (SETQ X (LIST 'B))))
X)
; the PUSH first evalutes (SETQ X (LIST 'A)) => (A)
; then evaluates (SETQ X (LIST 'B)) => (B)
; then modifies the CAR of (this latest value) to be ((A) . B).
; The result is (((A) . B)).
Documentation impact:
PUSH should more appropriately be described as:
"(PUSH Item Place) is roughly equivalent to (SETF Place (CONS Item Place))
except that the subforms of Place are evaluated only once, and Item is evaluated
before Place."
The phase "subforms of the reference" which appears several times in CLtL should
be made more specific to be "subforms of the macro call," referring to the
entire form that calls the generalized-variable manipulating macro.
Rationale:
This is the unstated intention of the page 97-100 discussion of
generalized-variable referencing macros, and indeed the intended definition of
"obvious semantics" for all macros.
Current practice:
Many implementations do not currently follow this evaluation order. In the form
(PUSH Item Place), Lucid, Franz, Kyoto and Xerox evaluate Place then Item.
Symbolics evaluates Item then Place.
For example, in Franz:
(macroexpand '(push (ref1) (car (ref2))))
(LET* ((#:G8 (REF2))
(#:G7 (CONS (REF1) (CAR #:G8))))
(EXCL::.INV-CAR #:G8 #:G7))
In Symbolics Common Lisp, it returns:
(LET* ((#:G5 (REF1))
(#:G4 (REF2)))
NIL
(SYS:RPLACA2 #:G4 (VALUES (CONS #:G5 (CAR #:G4)))))
Cost to implementors:
Minimal, PUSH etc. could simply be defined by the appropriate macros.
Cost to users:
No currently portable program should be affected. However, this is a minor
incompatible change for some implementations. No serious performance impact is
expected; while some macro expansions may appear to be more verbose, most
compilers deal reasonably with the required order of evaluation.
Benefits:
The implementation and semantics of PUSH become more well specified. This
removes a source of non-portability, abeit likely rare.
Esthetics:
Common Lisp defines order of evaluation as left-to-right; this clarification
ensures consistency across the language.
Discussion:
This seems to be the intent of most of the relevant language in CLtL.
For example, the second to last paragraph on page 99
"As an example of these semantic rules, in the generalized-variable reference
(setf reference value), the value form must be evaluated after all the subforms
of the reference because the value form appears to the right of them."
makes it clear that in this context the phrase "generalized-variable reference"
was meant to refer to the entire macro call, not just the Place, and that order
of evaluation rules are not limited to subforms of Places. We hope the
specification should adopt more consistent terminology.
Note that DEFINE-SETF-METHOD is immune to the exception specified about DEFMACRO
and DEFINE-SETF-METHOD, because since CLtL p.103 says about DEFINE-SETF-METHOD:
"This binding permits the body forms to be written without regard for
order-of-evaluation issues."
∂14-Feb-88 1341 X3J13-mailer Issue: SETF-FUNCTION-VS-MACRO (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:40:40 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:41:10 PST
Date: 14 Feb 88 13:40 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: SETF-FUNCTION-VS-MACRO (version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
line-fold: NO
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-134110-1441@Xerox>
This issue was distributed at the November 1987 meeting.
!
Issue: SETF-FUNCTION-VS-MACRO
References: SETF rules for what -place- can be (pp.94-7)
COMPILE function (p.438)
DEFUN macro (p.57)
DISASSEMBLE function (p.439)
DOCUMENTATION function (p.440)
FBOUNDP function (p.90)
FLET special form (p.113)
FMAKUNBOUND function (p.92)
FTYPE declaration (p.158)
FUNCTION special form (p.87)
FUNCTION declaration (p.159)
INLINE declaration (p.159)
NOTINLINE declaration (p.159)
LABELS special form (p.113)
SYMBOL-FUNCTION and setf of symbol-function (p.90)
TRACE macro (p.440)
UNTRACE macro (p.440)
Category: ADDITION
Edit history: Version 1, 13-Oct-87 Moon
(based on discussion among the CLOS working group)
Version 2, 26-Oct-87 Masinter, minor mods
Version 3, 4-Nov-87 Moon, small clarifications at KMP's urging
PROBLEM DESCRIPTION:
The Common Lisp Object System needs a well-defined way to relate the
name and arguments of a setting function to those of a reading function,
because both functions can be generic and can have user-defined methods.
We tried to hide the name and arguments of the setting function with
macrology, but the complexity got out of hand. It seems better to make
this information explicit; the version of the CLOS specification that
assumes the adoption of proposal SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
is much simpler in the relevant areas.
PROPOSAL (SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS):
Add to Common Lisp the concept of "setf functions". Right now, Common
Lisp only has "setf macros", which are defined by define-setf-method and
both forms of defsetf. Terminology:
- a "setf macro" is something that produces code (or other
specifications, as in define-setf-method) which, when evaluated,
will perform the effect of an invocation of setf.
- a "setf function" is something that is called to perform
directly the effect of an invocation of setf.
The form (setf (-name- ...) ...), when -name- is defined as a function
(rather than a macro) and no setf macro has been defined for -name-,
expands into a call to a setf function. The name of this setf function
is a list (setf -name-), where -name- is a symbol. The body of this
function is surrounded by an implicit block named -name-.
The functions, macros, special forms, and declarations defined in CLtL
and listed in the References section above need to be enhanced to accept
such lists in addition to symbols as function names, so that setf
functions can be defined and manipulated.
A setf function receives the new value to be stored as its first
argument. Thus, #'(setf foo) should have one more required parameter
than #'foo, the first required parameter is the new value to be stored,
and the remaining parameters should be the same as #'foo's parameters.
A setf function must return its first argument, since setf is defined
to return the new value.
A definition of a setf function can be lexically local, like a
definition of a reading function. The following rules specify the
behavior of SETF; note that these rules are ordered and the first rule
to apply supersedes any later rules. These rules are a consistent
extension of the current behavior of Common Lisp and the Cleanup
committee's resolution of issue GET-SETF-METHOD-ENVIRONMENT. Only
rule 4 is new with this proposal.
Rules for the macroexpansion of (setf (foo x) y):
(1) If the function-name foo refers to the global function definition,
rather than a locally defined function or macro, and if there is a
setf macro defined for foo, use the setf macro to compute the expansion.
(2) If the function-name foo is defined as a macro in the current scope,
use macroexpand-1 to expand (foo x) and try again.
(3) If the function-name foo is defined as a special form in the current
scope, signal an error.
(4) Expand into the equivalent of
(let ((#:temp-1 x) ;force correct order of evaluation
(#:temp-2 y))
(funcall #'(setf foo) #:temp-2 #:temp-1))
Note that rule 4 is independent of the scope of the function name
(setf foo). It does not matter if that scope is different from the
scope of the function name foo. This allows some nonsensical programs
to be written, but does not seem harmful enough to justify making more
complicated rules to compare the scopes of the two function definitions.
The above rules are actually implemented by GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE, rather than by the SETF macro itself.
Thus GET-SETF-METHOD generates the appropriate five values for a form
that is not a macro-invocation and does not have a defined setf macro.
Normally one does not define both a setf function and a setf macro
for the same reading function.
Normally one defines a local reading function and a local setf function
together in a single FLET or LABELS.
In the absence of any setf macro definition, SETF of a function expands
into a call to the setf function. This means that the setf function
only needs to be defined at run time, not compile time.
What CLtL says about (documentation foo 'setf) will not change.
Specifically, the setf documentation type applies just to defsetf (and
define-setf-method, that's an omission in CLtL). The documentation for
a setf function, as for any function, is retrieved by
(documentation '(setf foo) 'function).
Examples:
;If SETF of SUBSEQ was not already built into Common Lisp,
;it could have been defined like this
(defun (setf subseq) (new-value sequence start &optional end)
(unless end (setq end (length sequence)))
(setq end (min end (+ start (length new-value))))
(do ((i start (1+ i))
(j 0 (1+ j)))
((= i end) new-value)
(setf (elt sequence i) (elt new-value j))))
;Another example, showing a locally defined setf function
(defun frobulate (mumble)
(let ((table (mumble-table mumble)))
(flet ((foo (x)
(gethash x table))
((setf foo) (new x)
(setf (gethash x table) new)))
..
(foo a)
..
(setf (foo a) b))))
;get-setf-method could implement setf functions by calling
;this function when rules 1-3 do not apply
(defun get-setf-method-for-setf-function (form)
(let ((new-value (gensym))
(temp-vars (do ((a (cdr form) (cdr a))
(v nil (cons (gensym) v)))
((null a) v))))
(values temp-vars (cdr form) (list new-value)
`(funcall #'(setf ,(car form))
,new-value ,@temp-vars)
`(,(car form) ,@temp-vars))))
RATIONALE:
By making the names and arguments of setting functions explicit, CLOS is
considerably simplified. In addition, this can supersede any proposals
to introduce a lexically local form of defsetf; lexically local setf
functions serve the same needs.
Current code that resembles
(defsetf foo |setf FOO|)
(defun foo (x) ..)
(defun |setf FOO| (x new) ..)
or
(defsetf foo internal-foo-setter)
(defun foo (x) ..)
(defun internal-foo-setter (x new) ..)
can be, but is not required to be, replaced with the following code
(defun foo (x) ..)
(defun (setf foo) (new x) ..)
An advantage of this is that several disparate styles of using
DEFSETF can be replaced with a single common style of using
setf functions, making programs more standardized and readable.
CURRENT PRACTICE:
A few Common Lisp implementations already have a similar feature,
in that they allow setting functions named (SETF reader). We don't
know of any implementation that has precisely the proposed feature.
ADOPTION COST:
The main cost is generalization of a few functions to accept lists
beginning with SETF where they now accept only symbols. Implementations
must add a data structure to store the function definition of a setf
function, however, this can trivially be done with property lists or
generated symbols.
The cost of making the SETF macro expand into a call to a setf function,
when it does not find a setf macro or a regular macro to expand, is
negligible.
This will be an incompatible change for Symbolics, since it already has
setf functions but they do not take the same arguments as proposed here.
However, the change is considered worthwhile.
COST OF NON-ADOPTION:
Non-adoption of this proposal would be a significant roadblock to the
Common Lisp Object System. Some major rethinking of CLOS would be
required.
BENEFITS:
Allow CLOS to be defined without out-of-hand complexity.
Improve usability of SETF.
CONVERSION COST:
None, this is an upward-compatible change.
As with any language extension, some program-understanding programs may
need to be enhanced. A particular issue here is programs that assume
that all function names are symbols. They may use GET to access
properties of a function name or use EQ or EQL (perhaps via MEMBER or
ASSOC) to compare function names for equality. Such programs will need
improvement before they can understand programs that use the new
feature, but otherwise they will still work.
ESTHETICS:
SETF would be more esthetic, but less powerful, if it had only the
proposed setf functions and did not have setf macros. Such a major
incompatible change is of course out of the question; however, if setf
functions are stressed over setf macros, SETF will be much easier to
teach.
DISCUSSION:
Note that in Common Lisp, setf macro expansion is an operation on
function names, not on functions. It differs from some dialects of
Scheme, such as T, in this respect. This proposal does not attempt to
change that.
There was some concern about introducing the notion that the name of the
setf-function associated with FOO should be a list, (SETF FOO). This is
a considerable extension to the idea of a "function name", at least for
standard Common Lisp implementations that do not implement Lisp machine
style function-specs.
However, the CLOS unsuccessfully tried a number of alternatives.
Fundamentally the problem is that there has to be a name that the user
uses to define the thing and to talk about it. Trying to hide the name
just means you use a more obscure name, like an alternate syntax for
DEFUN or DEFUN-SETF. Another reason for making the name explicit is to
allow one to use FLET for the setf function -- something which would be
difficult if there is not a name-like entity that can be bound.
This proposal is not incompatible with other extensions to function
specifications present in some implementations.
The following related features were considered but are specifically
not being proposed at this time, since they are unnecessary for CLOS
and appear not to improve the simplicity and esthetics of the language:
a) Lexically local setf macros, that is, a cross between DEFSETF and
MACROLET. This does not appear to be logically necessary. Would all
three ways of defining lexically global setf macros need local
counterparts?
b) Define the meaning of defmacro or macrolet of (setf foo)?
This would be a fourth way to define a setf macro.
c) Enhance the definition of global setf macros, for example to
say that (MACRO-FUNCTION '(SETF FOO)) returns an expander function
that takes two arguments and returns five values.
d) Introduce a new name for SYMBOL-FUNCTION, since it accepts
non-symbols now.
e) Should one allow these extended function names in the car-position
of an expression to be evaluated? The extra complexity didn't seem
justified, instead, an explicit FUNCALL is required.
∂14-Feb-88 1352 X3J13-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:51:55 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:49:20 PST
Date: 14 Feb 88 13:49 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: REDUCE-ARGUMENT-EXTRACTION (version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-134920-1443@Xerox>
This issue is new.
!
Issue: REDUCE-ARGUMENT-EXTRACTION
References: REDUCE (pp. 251-252), :KEY arguments (p. 246),
the astronaut structure (pp. 312-313)
Category: ADDITION
Edit history: Version 1 by Pierson 5-Dec-87
Version 2 by Pierson 30-Dec-87
Version 3 by Masinter 13-Feb-88
Problem description:
REDUCE is the only one of the Common Lisp functions that modify or
search lists and sequences which does not accept a :KEY argument.
This complicates many uses of REDUCE.
Proposal (REDUCE-ARGUMENT-EXTRACTION:KEY):
Change the definition of REDUCE to take a :KEY keyword described as
follows:
If a :KEY argument is supplied, its value must be a function of one
argument which will be used to extract the values to reduce. The :KEY
function will be applied exactly once to each element of the sequence
in the order implied by the reduction order but not to the value of
the :INITIAL-VALUE argument, if any.
Example:
Using REDUCE to obtain the total of the ages of the possibly empty
sequence of astronauts ASTROS, would currently require:
(REDUCE #'+ (MAP 'LIST #'PERSON-AGE ASTROS))
If this proposal is adopted, the same result could be obtained without
creating a new list by:
(REDUCE #'+ ASTROS :KEY #'PERSON-AGE)
Rationale:
This proposal makes many common situations where REDUCE would be useful
much less cumbersome.
Current practice:
We know of no implementation which currently supports this feature.
Cost to Implementors:
This will require most implementations to make a trivial modification
to REDUCE. Implementations which wish to use this as an opportunity to
further optimize compiled calls to REDUCE will have to undertake more
work (which would be much more difficult today).
Cost to Users:
None, this is an upward compatible extension.
Cost of non-Adoption:
REDUCE will continue to be more difficult to use than other sequence
functions on sequences of complex objects.
Benefits:
REDUCE will become easier to use on sequences of complex objects. It
will be easier for compilers to convert some calls to REDUCE into
efficient loops.
Aesthetics:
Slightly damaged in one way. All :KEY arguments are currently defined
to be used for predicates, this proposal will implicitly broaden :KEY
to support general extraction for any purpose.
Slightly improved in another way. Many common situations where REDUCE
could be used would be easier to write and easier to later read.
Discussion:
Several members of the committee feel that the increased functionality
outweighs the damage to the definition of :KEY. No one has objected
to this change in the recent round of discussions.
There is some controversy over whether the "definition" of :KEY
arguments on page 246 of CLtL really constitutes a definition or just
an "unwritten rule".
∂14-Feb-88 1354 X3J13-mailer Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:54:18 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:54:43 PST
Date: 14 Feb 88 13:54 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-135443-1454@Xerox>
This issue is new.
!
Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
References: Sequences (pp245-261)
Issue REMF-DESTRUCTURING-UNSPECIFIED
(discussion of NREVERSE, NSUBSTITUTE)
Issue AREF-1D
Category: ENHANCEMENT
Edit history: 05-Feb-87, Version 1 by Touretzky
28-Apr-87, Version 2 by Pitman (variations on the theme)
26-Oct-87, Version 3 by Masinter (clean up for release)
11-Nov-87, Version 4 by Masinter (respond to comments)
5-Feb-88, Version 5 by Masinter
Description:
Common Lisp provides many useful operations on lists and vectors which don't
apply to arrays.
For example, one can FILL a vector with 0's, but not an array. One can REPLACE
the contents of one vector with another, but one can't do this for arrays. One
can verify that EVERY element of a vector has some property, but one can't do
this for arrays, and so on.
The programmer who wishes to use arrays instead of vectors must give up most of
the useful tools CLtL provides for manipulating sequences, even though there is
no intuitive reason why operations like FILL, REPLACE, and EVERY shouldn't work
on arrays.
Common Lisp already provides a facility called "displaced arrays" which can be
used to overlay one array on top of a portion of another, even if the two are of
different ranks, so that the two share storage or use the awkward convention of
creating a displaced array to the operand. However, creating a displaced array
merely to perform FILL, REPLACE or EVERY is awkward.
Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE):
1) Extend the definitions of sequence functions that either return their
argument sequences or return non-sequences so that they also allow arrays of
rank other than 1. These functions should treat array arguments as vectors
displaced to the array storage (in row-major format). The affected functions are
LENGTH, ELT, COUNT, FIND, POSITION, SOME, EVERY, NOTANY, NOTEVERY, REDUCE,
SEARCH, MISMATCH, FILL, REPLACE, SORT.
For example, suppose A is a 3x2x7 array. (LENGTH A) should return 42, and (ELT A
7) should return the same element as (AREF A 0 1 0). :START and :END keywords
would be interpreted relative to the vector, as would the results returned by
POSITION and SEARCH.
2) Extend the definitions of sequence functions whose result should be the same
shape as but not necessarily EQ to some argument. These functions should deal
with array arguments by returning an array of the same shape as the argument,
and operate on their argument in row-major order. The affected functions are
SUBSTITUTE, NSUBSTITUTE, REVERSE, NREVERSE, SUBSTITUTE-IF, NSUBSTITUTE-IF,
SUBSTITUTE-IF-NOT, NSUBSTITUTE-IF-NOT and MAP.
3) Sequence functions that modify the number of elements in the array remain
unchanged: it is an error to pass arrays of rank other than 1. (The functions
are not extended because the shape would be undefined.) The unaffected functions
are SUBSEQ, COPY-SEQ, CONCATENATE, MERGE, REMOVE, REMOVE-DUPLICATES, DELETE,
DELETE-DUPLICATES.
Note that EQUALP does -not- treat arrays as vectors. It is not a sequence
function, and it already has a well-defined behavior for arrays. To test whether
the arrays A and B, of different shapes, have the same elements, one might
write:
(AND (= (LENGTH A) (LENGTH B)) (EVERY #'EQL A B)).
Rationale:
This is a useful upward compatible extension with relatively low adoption cost.
Cost to Implementors:
This would involve a lot of changes to functions, but all of the changes are
likely to be minor. The presence of displaced arrays in the language already
guarantees that the internal storage format needed to back up these proposed
changes is already in place.
Cost to Users:
This change is upward compatible; current user code should run unmodified.
Benefits:
This proposal adds natural support for multi-dimensional arrays. Currently,
users must write nested DO loops every time they want to perform an array
operation equivalent to FILL, REPLACE, REDUCE, etc., or else they build
displaced vectors by hand and pass them to the sequence functions when
necessary. With this proposal, users of arrays do not have to use home-grown
utilities to duplicate functionality already primitively provided to users of
arrays. The sequence functions become useful in a variety of new situations.
Aesthetics:
This proposal extends sequence functions to cover arrays while neatly avoiding
the temptation to turn Common Lisp into a half-baked APL. Instead of trying to
provide a full set of array handling primitives (which would be needed to take
arbitrary k-dimensional slices out of n-dimensional arrays, or to apply an
operator across a specific dimension of a multidimensional array), it requires
just one rule:
treat arrays as displaced vectors where it is well-defined.
Current Practice:
We know of no current implementation of this proposal.
Discussion:
This issue was discussed by the cleanup committee at length; what follows is
only a brief summary of the discussion.
An alternative considered was to only affect those functions which didn't
explicitly depend on the shape of the array; that is, to modify COUNT, SOME,
EVERY, NOTANY, NOTEVERY, FILL, REPLACE, SUBSTITUTE, NSUBSTITUTE, and MAP, and
expressly forbid arrays as arguments to other sequence functions, including
LENGTH, ELT, FIND, POSITION, REDUCE, SEARCH, MISMATCH, REVERSE, NREVERSE, SORT,
MAP, as well as SUBSEQ, COPY-SEQ, CONCATENATE, MERGE, REMOVE, REMOVE-DUPLICATES,
DELETE, DELETE-DUPLICATES. This would be less controversial, since it includes
only those functions which do not deal with positional information. Some hedging
over REDUCE and FIND, which often have non-positional uses, were considered.
Touretzky supports SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE. He's been
building displaced vectors to pass to sequence functions when necessary and
really dislikes it.
We considered but discarded as unworkable an alternative where POSITION and FIND
might deal with "positions" as lists of array subscripts.
At one point, this proposal included an extension to COERCE to allow COERCE to
translate from array types to sequences, but it was thought better to separate
out COERCE. We considered a proposal to only introduce a change to COERCE, and
require users who want to operate on arrays explictly perform, e.g., (COUNT
item (COERCE x 'SEQUENCE)). This alternative would have the lowest adoption cost
but was deemed awkward.
Sequence functions like FILL and COUNT are already generalized to arrays in
non-Lisp contexts; in English we use the generalized forms all the time, e.g.,
"count the number of 1's in this matrix."
There is some concern that this proposal makes the requirement for row-major
ordering of internal storage for arrays even more evident. While such an
internal ordering is implied by the ability to create displaced arrays and the
AREF-1D proposal, this proposal adds yet another constraint.
The general reason for opposing this change is that it adds more mechanism than
it is worth. The general reason for liking it is that it adds generality at
little cost.
∂14-Feb-88 1406 X3J13-mailer Issue: SHADOW-ALREADY-PRESENT (version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 14:05:20 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 14:04:22 PST
Date: 14 Feb 88 14:03 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: SHADOW-ALREADY-PRESENT (version 4)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-140422-1472@Xerox>
This issue is new.
!
Issue: SHADOW-ALREADY-PRESENT
References: CLtL p.186
Category: CLARIFICATION/CHANGE
Edit history: Version 1 Moon 24 Aug 87
Version 2 Moon 27 Aug 87 incorporate JonL's suggestions
Version 3 Masinter 26-Oct-87
Version 4 Masinter 10-Nov-87
Problem description:
The description of the SHADOW function can be interpreted as saying that the
function has no effect, if the symbol is already present in the package. This
happens if the third sentence in the description ("then nothing is done") is
interpreted as applying to the entire description rather than just to the fourth
sentence.
SHADOW is said to take symbols as arguments, however only the print-name is
meaningful for this operation (that fact is already documented).
Proposal SHADOW-ALREADY-PRESENT:WORKS:
1) The SHADOW function always adds the symbol to the PACKAGE-SHADOWING-SYMBOLS
list, even when the symbol is already present in the package.
2) The first argument to SHADOW is allowed to be or contain strings as well as
symbols. The specification "the print name of each symbol is extracted" is to be
modified accordingly.
Test Case:
;;; SHADOW always adds the symbol to the PACKAGE-SHADOWING-SYMBOLS
;;; list of a package
(make-package 'test-1)
(intern "TEST" (find-package 'test-1))
(shadow 'test-1::test (find-package 'test-1))
(assert (not (null (member 'test-1::test (package-shadowing-symbols
(find-package 'test-1))))))
(make-package 'test-2)
(intern "TEST" (find-package 'test-2))
(export 'test-2::test (find-package 'test-2))
(use-package 'test-2 (find-package 'test-1)) ;should not error
;;; To test the use of strings in place of symbols
;;; change the third line of the test case to
;;; (shadow "TEST" (find-package 'test-1))
;;; Note the use of capital letters in the string.
Rationale:
CLtL p. 180 describes a name conflict problem that can occur when calling the
function USE-PACKAGE. The name conflict is between a symbol directly present in
the using package and an external symbol of the used package. This name conflict
may be resolved in favor of the symbol directly present in the using package by
making it a shadowing symbol. For this to work, SHADOW must add the symbol to
the PACKAGE-SHADOWING-SYMBOLS list even when it is already present in the
package.
Since only the print name of a symbol argument is meaningful, a string should
also be accepted. This is particularly useful to avoid problems when compiling
code in one package environment and loading it into a slightly different package
environment, where the symbol that was referred to at compile time may not be
present at load time. This is particularly important because the symbol
referred to by the print name may be changed by evaluation of the SHADOW form.
A close reading of CLtL shows that one can already use (shadow '#:bar) in place
of (shadow 'bar), to achieve much the same effect as (shadow "BAR"). But the
user should not have to play such games, strings should be accepted.
Current practice:
Symbolics and Spice Lisp add the symbol to the PACKAGE-SHADOWING-SYMBOLS list,
even when the symbol is already present in the package. Kyoto Common Lisp,
Lucid Common Lisp, and Xerox Common Lisp ignore SHADOW when the symbol is
already present in the package. It seems likely that we will find several
implementations in each camp.
SHADOW accepts strings in Symbolics Common Lisp.
Cost to implementors:
This should be a minor change to implementations that do not currently work this
way.
Cost to users:
Technically this would be an incompatible change to implementations that do not
already behave as proposed, however it is difficult to conceive of a user
program that would require any conversion to cope with the change. Some users
might want to remove kludges that were only necessary to get around the former
misbehavior of SHADOW.
Cost of non-adoption:
Inconsistency among implementations and lack of a clear way to resolve the name
conflict mentioned in Rationale.
Benefits:
Consistency among implementations and fewer mysterious package problems.
Esthetics:
The proposal would remove an unnecessary special case, thus simplifying the
language slightly.
Discussion:
The issue was raised by Dieter Kolb on the Common-Lisp mailing list.
It would be useless for SHADOW to fail to put a symbol that is already present
in the package onto the PACKAGE-SHADOWING-SYMBOLS list. Moon believes CLtL
intended to describe what is being proposed, but unfortunately used ambiguous
language.
The cleanup committee endorses this proposal.
∂14-Feb-88 1408 X3J13-mailer
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 14:08:04 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 14:08:41 PST
Date: 14 Feb 88 14:08 PST
From: Masinter.pa@Xerox.COM
Issue: SHARPSIGN-PLUS-MINUS-PACKAGE (Version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-140841-1482@Xerox>
This issue had not been distributed before.
!
Issue: SHARPSIGN-PLUS-MINUS-PACKAGE
References: #+ (p. 358), #- (p. 359), *FEATURES* (p. 448)
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by Pitman 01-Mar-87
Version 2 by Masinter 10-Nov-87
Version 3 by Masinter 14-Nov-87
Problem Description:
No information is provided in the description of #+ and #- (pp. 358-359) about
what package the features are read on.
In some systems, the current package is used. Since there is no wording in CLtL
to the contrary, it's reasonable to assume that this would be done, but a
consequence of this is that you must be much more sensitive to the package
you're in at any given time when using #+ or #- even for system-provided
features. (This is a problem if the LISP package can contain only the symbols in
CLtL because system-provided features will likely not have the names of symbols
on LISP and hence will require package prefixes. Having a symbol named
LISP:SYMBOLICS or LISP:LUCID would not be possible, so something like
#+Symbolics would not be possible; you'd have to write #+SYSTEM:SYMBOLICS or
some such, which might get a read error in a non-Symbolics implementation that
didn't export SYMBOLICS from SYSTEM...)
In some systems, a canonical package (such as KEYWORD) is used. This means that
package prefixes are rarely necessary in sharpsign conditionals for
system-provided features regardless of the current package or restrictions about
what may be in LISP. (For example, the KEYWORD package can have any symbol so
it's not a problem to push :SYMBOLICS or :LUCID on *FEATURES*).
This has implications about what goes on the *FEATURES* list (p. 448).
Proposal (SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD):
Specify that the default package while reading feature specs is the keyword
package. Other packages may be designated by use of explicit package prefixes.
Symbols on *FEATURES* may be in any package but that in practice they will
mostly be on the keyword package because that's the package #+/#- uses by
default. If symbols in a package other than keyword appear on *FEATURES*, they
will be seen by #+/#- only if marked by explicit package prefixes in the
written feature-spec.
Clarify that the package of the IEEE-FLOATING-POINT symbol mentioned on p. 448
is KEYWORD.
Rationale:
Making the behavior of #+ and #- well defined is important for people writing
portable code that manipulate *FEATURES* directly.
Current Practice:
Some implementations bind *PACKAGE* while reading feature specs and others do
not.
Adoption Cost:
Changes to implementations to make them conform should be fairly minor if not
trivial.
Benefits:
As currently specified, using #+ and #- in truly portable code can have
bootstrapping problems, since it is sometimes required to conditionally set up
*FEATURES* in different ways for different systems.
Conversion Cost:
Few changes to user code will be required; code that uses #+ and #- will
continue to work, although code that manipulates *FEATURES* directly may require
editing.
Aesthetics:
Most users would perceive this as a bug fix either to CLtL or to certain
implementations.
Discussion:
The cleanup committee supports this proposal.
It might be reasonable to suggest that only vendors should add keyword symbols
to the *FEATURES* list, and that users should add features on their personal
packages so that collisions due to user applications were less likely. This idea
might be a subject of controversy though, so is not part of this proposal.
It would be useful to create a non-binding registry of feature names (and
package names) already in use, so that Lisp implementors could pick otherwise
unused feature names, and users who wanted to write portable code could know
what feature names were preferred.
∂14-Feb-88 1455 X3J13-mailer Common Lisp cleanup issue status to X3J13
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 14:54:40 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 14:55:15 PST
Date: 14 Feb 88 14:54 PST
From: Masinter.pa@Xerox.COM
Subject: Common Lisp cleanup issue status to X3J13
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-145515-1510@Xerox>
!
This is the list of issues distributed for the March 1988 X3J13 meeting:
- ADJUST-ARRAY-DISPLACEMENT (Version 4, 23-Nov-87)
(Interaction of ADJUST-ARRAY and displaced arrays)
- APPEND-DOTTED (Version 5, 14-Jan-88)
(What happens to CDR of last CONS? in other
than last arg?)
- AREF-1D (Version 7, 14-Nov-87)
(Add a new function for accessing arrays with row-major-index)
Version 5 conditionally passed X3J13/Jun87
Version 7 passed X3j13/Nov87
- ASSOC-RASSOC-IF-KEY (Version 4, 23-Nov-87)
(Extend ASSOC-IF, etc. to allow :KEY)
- COLON-NUMBER (Version 1, 22-oct-87)
(Is :1 a number, a symbol, or undefined?)
Version 1 passed X3J13/Nov87
- COMPILER-WARNING-BREAK (Version 4,23-Nov-87 )
(Does *BREAK-ON-WARNING* affect the compiler?)
- DECLARE-MACROS (Version 3, 5-FEB-88)
(Disallow macros expanding into declarations.)
- DEFVAR-DOCUMENTATION (Version 2, 23-Nov-87)
(Documentation string is not evaluated.)
- DISASSEMBLE-SIDE-EFFECT (version 3, 21 Jan 88)
(DISASSEMBLE doesn't smash the def if not compiled)
- DO-SYMBOLS-DUPLICATES (Version 3, 23-Nov-87)
( DO-SYMBOLS can the same symbol twice?)
- DRIBBLE-TECHNIQUE (Version 2, 14-Feb-88)
(dribble can't be used programmatically)
- FLET-DECLARATION (Version 2, 2 Feb 88)
(Allow declarations in FLET, MACROLET)
- FORMAT-COMMA-INTERVAL (Version 2, 15 June 87)
(paramerize number of digits between commas)
Version 2 passed X3J13/Nov87
- FORMAT-COLON-UPARROW-SCOPE (Version 3, 5 Feb 88)
(what iteration does ~:↑ exit from?)
- FUNCTION-TYPE-KEY-NAME (Version 3, 5 Feb 88)
(allow &KEY (:KEYNAME type)) in FUNCTION decls )
- FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3, 13-Feb-88)
(allow &rest <type> in function types to refer to element
type)
- FUNCTION-TYPE (Version 9, 13-Feb-88)
(Change definition of FUNCTIONP, function type ...)
- GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
(Environment argument for GET-SETF-METHOD)
Version 4 conditionally passed X3J13/Jun87.
Version 5 passed X3J13/Nov87.
- KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8, 8-Nov-87)
(&KEY arguments not in keyword package?)
Version 6 conditionally passed X3J13/Jun87.
Version 8 passed X3J13/Nov87
- PATHNAME-STREAM (Version 6, 14-Nov-87)
(PATHNAME only works on file streams)
Version 2 conditionally passed X3J13/Jun 87
Version 6 passed X3J13/Nov 87
- PATHNAME-SYMBOL (Version 5, 5-Feb-88)
(Do symbols automaticly coerce to pathnames?)
- PUSH-EVALUATION-ORDER (Version 5,25-Nov-87)
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
- REDUCE-ARGUMENT-EXTRACTION (version 3, 13-Feb-88)
(Add :KEY to REDUCE)
- SETF-FUNCTION-VS-MACRO (Version 3, 4-Nov-87)
(Allow (DEFUN (SETF FOO) ..))
- SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5, 5-Feb-88)
(let FIND, SUBSTITUTE etc work on multi-dimensional arrays)
- SHADOW-ALREADY-PRESENT (Version 4, 10-Nov-87 23:59:43)
(What does SHADOW do if symbol is already there?)
- SHARPSIGN-PLUS-MINUS-PACKAGE (version 3, 14-Nov-87)
(*FEATURES* are in the keyword package)
!
The following issues were mailed prior to the June 1987 meeting and passed at
that meeting; they will not be distributed again except by request.
- COMPILER-WARNING-STREAM (Version 6, 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
Version 6 passed X3J13/Jun87
- DEFVAR-INIT-TIME (Version 2, 29-May-87)
(DEFVAR initializes when evaluated, not later.)
Version 2 passed X3J13/Jun87.
- DEFVAR-INITIALIZATION (Version 4, Jun-87)
((DEFVAR var) doesn't initialize)
Version 4 passed X3J13, Jun87.
- FLET-IMPLICIT-BLOCK (Version 6, 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Version 6 passed X3J13/Jun87.
- FORMAT-ATSIGN-COLON (Version 4, 5-jun-87)
(@: == :@ in format)
Version 4 passed X3J13/Jun87.
- FORMAT-OP-C (Version 5, 11-Jun-87)
(What does ~C do?)
Version 5 passed X3J13/Jun87.
- IMPORT-SETF-SYMBOL-PACKAGE (Version 5, 11-Jun-87)
(Does IMPORT affect home package?)
Version 5 passed X3J13/Jun87.
- PRINC-CHARACTER (Version 3)
(PRINC behavior on character objections)
Version 3 passed X3J13/Jun87.
!
For your information only, the following issues are still under consideration by
the cleanup committee. Volunteers to help out with the preparation of issue
writeups are welcome. If you would like to review the mail discussion on a given
topic, please let me know and I will forward it to you.
- ADJUST-ARRAY-FILL-POINTER
(Interaction of Adjust-ARRAY and fill pointers.)
Need volunteer to write up.
- CONSTANT-SIDE-EFFECTS (not yet submitted)
(It is an error to do destructive operations on constants in code,
defconstant.)
Discussed 12/86 - 1/87
Will take on if no compiler proposal
- DATA-TYPES-HIERARCHY-UNDERSPECIFIED (not yet submitted)
(Should STREAM, PACKAGE, PATHNAME, READTABLE, RANDOM-STATE be
required to be disjoint from other types?)
From CLOS committee, not yet submitted
- DECLARATION-SCOPE (Version 2, 2-Feb-88)
(What is the scope of SPECIAL declarations?
INLINE declarations? where can declarations be placed?)
- DECLARE-TYPE-EXACT (from Kempf as EXACT-CLASS)
(Want to be able to declare (EQ (TYPE-OF X) 'Y), i.e.,
not a subclass.)
Useful after CLOS
- DEFMACRO-BODY-LEXICAL-ENVIRONMENT (not yet submitted)
What is the lexical environment of DEFTYPE, DEFINE-SETF bodies?
Mail 11-12 Oct 87 on common-lisp
Interacts with compiler proposal?
- DEFSTRUCT-SLOTS-CONSTRAINTS (not yet submitted/issues file)
(p 307) "Allow a call to DEFSTRUCT to have no slot-descriptions.
Specify that it is an error for two slots in a single DEFSTRUCT to
have the same name. If structure A includes structure B, then no
additional slot of A may have the same name as any slot of B."
Need volunteer to sort out DEFSTRUCT issues post-CLOS.
- DEFSTRUCT-DEFAULT-VALUE-EVALUATION (not yet submitted/issues file)
(p 305) "The default value in a defstruct slot is not evaluated
unless it is needed in the creation of a particular structure
instance. If it is never needed, there can be no type-mismatch
error, even if the type of the slot is specified, and no warning
should be issued."
Need volunteer to sort out DEFSTRUCT issues post-CLOS.
- EQUAL-STRUCTURE (not yet submitted)
(Mail Nov 87 on Common Lisp: EQUAL on DEFSTRUCT structures.)
What do EQUAL EQUALP and friends do
on structures?
(Need volunteer.
ALarson@HI-MULTICS.Arpa, edsel!jonl@labrea.stanford.edu,
Okuno@SUMEX-AIM.STANFORD.EDU, goldman@vaxa.isi.EDU?)
- FILE-LENGTH-PATHNAME (not submitted, from ISSUES.TXT)
(P 425) "Generalize FILE-LENGTH to accept any filename, not just
an open file-stream. Let it take a keyword argument :ELEMENT-TYPE,
defaulting to STRING-CHAR for non-stream arguments and to the
element-type of the stream for a stream argument."
Need volunteer to write up.
- FILE-WRITE-DATE-IF-NOT-EXISTS (from Weinreb, no formal proposal)
(What does FILE-WRITE-DATE do if no such file?)
"there should not be a formal proposal for fixing the file-write-date
ambiguity until we are at the point where we can make proposals
that discuss signalling named conditions. "
Need volunteer.
- FORMAT-NEGATIVE-PARAMETERS (mail 19 May 87, no formal proposal)
"format parameters are assumed to be non-negative integers except
as specifically stated"
Need volunteer.
- FUNCTION-ARGUMENT-TYPE-SEMANTICS (not yet submitted)
(Change semantics of argument types in function declarations.)
- FUNCTION-SPECS (not yet submitted)
(add "function specs" for defun, trace etc)
beyond SETF-FUNCTION-VS-MACRO.
(SMH!franz@ucbarpa.berkeley.edu, JonL, RWK)
- GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
merge with other controls for unsolicited messages?
- LAST-N (version 1, 4-DEC-87)
(Extend LAST to take an optional N)
Needs rewrite as per Moon
- LISP-SYMBOL-REDEFINITION (no formal proposal yet)
Is it legal to redefine symbols in the LISP package?
Mail 14-Aug-87
Merge with SPECIAL-FORM-SHADOW
Needs volunteer
- LOAD-TIME-EVAL (Versin 4, 2 Feb 88)
(evaluation when compiled file is loaded)
- MACRO-FUNCTION-ENVIRONMENT
(Add environment argument to MACRO-FUNCTION?)
re-extracted from ENVIRONMENT-ARGUMENTS
CLOS committee to submit?
- PATHNAME-SUBDIRECTORY-LIST (Version 1, 18-Jun-87)
How to deal with subdirectory structures in pathname functions?
make :DIRECTORY a list?
Need volunteer to rewrite.
- PATHNAME-UNSPECIFIC-COMPONENT (not yet submitted)
Mail Aug 87 discussion
How to deal with logical devices, :unspecific components, etc
in pathname functions
RWK@YUKON.SCRC.Symbolics.COM may submit proposal.
- PEEK-CHAR-READ-CHAR-ECHO (Version 1, 3 March 87)
(interaction between PEEK-CHAR, READ-CHAR and streams made by
MAKE-ECHO-STREAM)
"Fixing echo streams is fine, but I don't think that
it is appropriate for the standard to specify how terminal
interaction must or even ought to work."
- PROCLAIM-LEXICAL (Version 5, 14-Nov-87)
(add LEXICAL, GLOBAL, CONSTANT proclaimation)
some serious problems
- PROMPT-FOR (Version 1)
(add new function which prompts)
Tabled until re-submitted.
- REMF-DESTRUCTION-UNSPECIFIED (Version 2, 30-Oct-87 )
(Specification of side-effect behavior in CL)
DEFINED, VAGUE and IN-BETWEEN
- REMF-MULTIPLE (Version 1, 26 Jan 88)
(What does REMF do if it sees more than one INDICATOR?)
- REQUIRE-PATHNAME-DEFAULTS (Version 1, 15-Oct-87)
(where does REQUIRE look for files?)
- REST-LIST-ALLOCATION (not yet submitted)
(APPLY #'LIST X) == (COPY-LIST X)?
need volunteer
- SETF-METHOD-FOR-SYMBOL (Version 3, 11-Nov-87)
(Change recommendation for (get-setf-method symbol)?)
- SETF-SUB-METHODS (version 1, 12-Feb-88)
(more careful definition of order of evaluation
inside (SETF (GETF ...) ...) )
- SHARPSIGN-PLUS-MINUS-NUMBER
(Is #+68000, #-3600 allowed?)
Mild disagreement: it is an error?
- SPECIAL-FORM-SHADOW (no formal proposal)
(Is it OK to shadow a special form with FLET, LABELS, MACROLET?)
In discussion, no formal proposal submitted.
- SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
Forwarded to character committee.
- STANDARD-INPUT-INITIAL-BINDING (Version 1, 19 Jan 88)
Move text of Test case/Example to Problem description.
Somewhere between completely undefining and current situation is
wanted.
- STREAM-CLASS-ACCESS (No formal proposal)
(Originally FOLLOW-SYNONYM-STREAM 19-DEC-86)
Define stream accessors as if synonym-stream two-way-stream etc
were CLOS classes?
Need volunteer
- STRUCTURE-DEFINITION-ACCESS (No formal proposal)
(access to slot accessors for DEFSTRUCT etc.)
Need volunteer to write up
- SUBSEQ-OUT-OF-BOUNDS (from ISSUES file, no formal proposal)
(p 246) "Specify that it is an error for the SUBSEQ indices or any
:START or :END argument have a negative index or point past the end
of the sequence in question. (With respect to whether signalling is
required, this error will be treated the same as array
out-of-bounds.)"
Need volunteer to write up
- TAILP-NIL (no formal proposal yet)
(Operation of TAILP given NIL)
Needs writeup in current format.
- TRACE-FUNCTION-ONLY (Version 5, 9-NOV-87)
(Allow trace for SETF functions, macros, etc.)
Environment extension?
- UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3, 27-Oct-87)
(What happens with non-local exits out of UNWIND-PROTECT
cleanup clauses?)
- VECTOR-PUSH-EXTEND-DEFAULT (no proposal yet)
CLtL says that vectors are extended by a "reasonable" amount. What's that?
∂16-Feb-88 0903 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 09:03:05 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 16 Feb 88 08:56:10-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA11758; Tue, 16 Feb 88 09:01:09 PST
Date: Tue, 16 Feb 88 09:01:09 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8802161701.AA11758@Tenaya.stanford.edu>
To: faculty@score
Subject: lunch
Today's lunch (Tuesday, Feb. 16) will feature Rebecca Lasher,
Paul Moser, Eleanor Goodchild talking with us about plans for
libraries in the Near West Campus. The library people are
valiantly trying to find out what the various departments want,
and they are finding some conflicting wants. Here is a chance
to make your views known. -Nils
∂16-Feb-88 1045 X3J13-mailer March 1988 agenda questions
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 10:45:00 PST
Received: by labrea.Stanford.EDU; Tue, 16 Feb 88 10:45:09 PST
Received: from sunvalleymall.lucid.com by edsel id AA03090g; Tue, 16 Feb 88 10:16:15 PST
Received: by sunvalleymall id AA28197g; Tue, 16 Feb 88 10:21:23 PST
Date: Tue, 16 Feb 88 10:21:23 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8802161821.AA28197@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: March 1988 agenda questions
I would like to prepare the agenda next week.
If you have something that should be discussed or voted on at the
March meeting please let me know what it is, the Document number
(if any) and approximate time needed.
Thanks!
---jan---
∂16-Feb-88 1312 HADDAD@Sushi.Stanford.EDU Reminder: Xerox BATS this Friday
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 13:12:08 PST
Date: Tue 16 Feb 88 13:03:49-PST
From: Ramsey Haddad <HADDAD@Sushi.Stanford.EDU>
Subject: Reminder: Xerox BATS this Friday
To: su-events@Sushi.Stanford.EDU, aflb.su@Sushi.Stanford.EDU
Message-ID: <12375261879.17.HADDAD@Sushi.Stanford.EDU>
BATS at PARC will be held on Friday, February 19, from 10 am to 3 pm.
Anyone who is going and hadn't told me so, should let me know so that
we can assure you a lunch.
10 AM: LOWER BOUNDS ON THE STRENGTH OF CRYPTOGRAPHIC ASSUMPTIONS
Steven Rudich, UC-Berkeley
11 AM: A TRADEOFF BETWEEN SPACE AND EFFICIENCY FOR ROUTING TABLES
David Peleg, Stanford
12 noon: lunch
1 PM: CONSTRUCTION AND APPLICATION OF EUCLIDEAN MAXIMUM SPANNING TREES
Frances Yao, Xerox PARC
2 PM: COVERING ORTHOGONAL POLYGONS WITH STAR POLYGONS
Arvind Raghunathan, UC-Berkeley
----------------------------------------
Driving Directions: Xerox PARC is at 3333 Coyote Hill Rd., Palo Alto.
The best way to get here from almost anywhere distant is to take
I-280, get off at Page Mill Rd., go east 1/2 mile, turn right on
Coyote Hill Rd, pass grazing horses, and finally turn left into PARC,
just over the crest of the hill. Park in the visitor's parking, or
any legal spot (including the Xerox building across the street) if
that lot is full. Enter at the auditorium entrance, down some stairs
which are to the left when one faces the building from the visitors's
parking lot.
-------
∂16-Feb-88 1506 @Sushi.Stanford.EDU:AFRATI@Score.Stanford.EDU Re: Reminder: Xerox BATS this Friday
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 15:04:23 PST
Received: from Score.Stanford.EDU by Sushi.Stanford.EDU with TCP; Tue 16 Feb 88 14:57:36-PST
Date: Tue 16 Feb 88 14:57:31-PST
From: Foto Afrati <AFRATI@Score.Stanford.EDU>
Subject: Re: Reminder: Xerox BATS this Friday
To: HADDAD@Sushi.Stanford.EDU
cc: su-events@Sushi.Stanford.EDU, aflb.su@Sushi.Stanford.EDU,
AFRATI@Score.Stanford.EDU
In-Reply-To: <12375261879.17.HADDAD@Sushi.Stanford.EDU>
Message-ID: <12375282577.27.AFRATI@Score.Stanford.EDU>
I intend to go to BATS.
My name is Foto Afrati
-------
∂16-Feb-88 1527 AAAI-OFFICE@SUMEX-AIM.Stanford.EDU Council Meeting & Hotel Accomodations
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 15:23:02 PST
Date: Tue, 16 Feb 88 15:13:10 PST
From: AAAI <AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>
Subject: Council Meeting & Hotel Accomodations
To: officers: ;
cc: aaAI-OFFICE@SUMEX-AIM.Stanford.EDU
Telephone: (415) 328-3123
Postal-Address: 445 Burgess Drive, Menlo Park, CA 94025
Message-ID: <12375285426.12.AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>
For those attending the March 24th meeting, may I suggest you sign up for
one of the discount hotel rooms made available for Symposium attendees.
If you need a registration booklet which contains the hotel registration
info, notify me soon.
If you have other questions about your accomodations, please contact me.
-Claudia
-------
∂16-Feb-88 1530 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Hash functions
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 15:30:14 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 16 Feb 88 15:18:56-PST
Received: by lindy.stanford.edu; Tue, 16 Feb 88 15:25:05 PST
Received: by Forsythe.Stanford.EDU; Tue, 16 Feb 88 15:22:11 PST
Received: by BYUADMIN (Mailer X1.25) id 1877; Tue, 16 Feb 88 16:21:40 MST
Date: Tue, 16 Feb 88 16:44:22 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
ND HECN E-mail Postmaster <INFO%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Resent-From: ND HECN E-mail Postmaster <INFO@NDSUVM1>
Comments: Originally-From: "Pat (Lewis,Pat J)" <LEWIS@GRIN1.Bitnet>
From: ND HECN E-mail Postmaster <INFO%NDSUVM1.BITNET@forsythe.stanford.edu>
Subject: Hash functions
To: Local Distribution <aflb.tn@sushi.stanford.edu>
Landed in our Bit Bucket...
----------------------------Original message----------------------------
Well, I don't claim to be an expert on the subject, but a linear congruence
would seem to me to be the best approach. Something of the form:
index = (a * key + c) mod m
where m is the table size and a and c are relatively prime to m would
do pretty well. On our system (VAX) I let the modulus operation be handled
by what's left over after arithmetic overflow since overflow doesn't cause
a visible error. So the function can really be written as:
index = a * key + c
as long as a and c are given appropriate values. This is a quick and
efficient method and gives good pseudo-random index values. Hope that
helps.
Pat Lewis
Grinnell College User Consultant
LEWIS@GRIN1.BITNET
∂16-Feb-88 2122 X3J13-mailer March 1988 agenda questions
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 21:22:35 PST
Received: by labrea.Stanford.EDU; Tue, 16 Feb 88 21:21:45 PST
Received: from bhopal.lucid.com by edsel id AA05999g; Tue, 16 Feb 88 21:07:02 PST
Received: by bhopal id AA02339g; Tue, 16 Feb 88 21:12:15 PST
Date: Tue, 16 Feb 88 21:12:15 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8802170512.AA02339@bhopal.lucid.com>
To: edsel!jlz@labrea.Stanford.EDU
Cc: x3J13@sail.Stanford.EDU
In-Reply-To: Jan Zubkoff's message of Tue, 16 Feb 88 10:21:23 PST <8802161821.AA28197@sunvalleymall.lucid.com>
Subject: March 1988 agenda questions
The four of us -- smh, rwk, jonl, and rg -- have an issue that needs more
time than a few minutes of cleanup committee covering: the extension of
names for definitions (sometimes referred to as "function specs"). Steve
(Haflich) has the problem description and issues written down, and Bob
(Kerns) has a proposed implementation. It would probably take 10 minutes
to present the issue, and conceivably would be met by 5-20 minutes of
unmitigated flaming from the floor after it is presented.
-- JonL --
∂17-Feb-88 1213 REGES@Score.Stanford.EDU Courses & Degrees
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 88 12:13:01 PST
Date: Wed 17 Feb 88 12:02:42-PST
From: Stuart Reges <REGES@Score.Stanford.EDU>
Subject: Courses & Degrees
To: faculty@Score.Stanford.EDU
Office: CS-TAC 22, 723-9798
Message-ID: <12375512897.30.REGES@Score.Stanford.EDU>
Most of you have gotten descriptions from Claire Stager, so I assume you
realize that we are starting our annual process of editing our entry in Courses
& Degrees. They make us turn in our corrections early because the typesetting
process takes many months. I actually tried once to see if we could bring them
into the modern age, even offering to potentially typset the entire catalogue
on our APS, but they weren't interested. So we have to live with their
deadlines.
I understand the procrastinating tendencies of this department probably better
than anyone else, because I'm one of the worst offenders. As a result, I have
worked diligently to uncover the best possible gaming of the system. Let me
explain what we can do:
o We have until March 1st to submit major changes. Major changes
are at the level of course description bodies. If we want wording
changes or additions/deletions, we MUST submit them by March 1st.
We can try submitting later, but there is no guarantee that they
will be accepted. So everyone should be working very hard right
now to get their course descriptions done. Claire has asked for
them by this Friday because she has to process them before they go
over. If someone needs to submit late, please okay with me first.
o We have until May 1st to submit minor changes. Last year I made use
of this fact to give us more time to figure out the staffing grid.
So we can delay the process of figuring out who is teaching what and
in what quarter and at what time. I plan to start this process
soon. We have to involve the EE and SITN folks, because we need to
negotiate for TV time slots.
o This year I managed to push the university people one bit closer to
flexibility. They have agreed that changes to prerequisite listings
will also be considered minor changes, which gives us until May 1st.
I know that some individuals and groups are still unsure of what they want to
do next year. If you are in that situation, I suggest the following. Come up
with the right number of course placeholders and give them numbers, titles, and
descriptions. In worst case, be vague. That gives you some time to decide the
exact scheduling and the prereq relationships.
-------
∂17-Feb-88 1311 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Discussion about list on rewriting systems
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 88 13:11:37 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Wed 17 Feb 88 12:59:51-PST
Received: by lindy.stanford.edu; Wed, 17 Feb 88 13:06:23 PST
Received: by Forsythe.Stanford.EDU; Wed, 17 Feb 88 13:04:35 PST
Received: by BYUADMIN (Mailer X1.25) id 2405; Wed, 17 Feb 88 14:02:20 MST
Date: Wed, 17 Feb 88 10:13:06 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Victor S. Miller" <victor@ibm.com>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Victor S. Miller" <victor@ibm.com>
Subject: Discussion about list on rewriting systems
To: Local Distribution <aflb.tn@sushi.stanford.edu>
The following was received by Theory Net, but never posted.
Victor
------------------------------------------------------------------------
Date: Tue, 2 Feb 88 16:40:30 PST
From: lescanne@poincare.crin.fr
Subject: a mailing on termination of rewriting systems
----------------------------------------------------------------------
| A mailing list on termination of rewriting systems and applications |
----------------------------------------------------------------------
Termination of rewriting systems is a very interesting topics with a
lot of applications. We are many people working in the field and we
do not know well what each other does and we like to know as soon as
possible the most recent results.
This is why we would like to start a mailing list on "Termination of
rewriting systems and applications". This can allow us to exchange
informations on recent reports and contributions, on open problems and
hot topics. This can also be the place for tracking results or asking
questions to the community.
If there are many people interested, this mailing list will be
moderated by one of us. The electronic address will be
termination@crin.crin.fr
Please send mail at this address.
---- Pierre LESCANNE ----- ------Isabelle GNAEDIG -----
lescanne@poincare.crin.fr gnaedig@prouve.crin.fr
Please forward this mail to people who could be interested.
------------------------------------------------------------------------
Date: Wed, 03 Feb 88 15:41:38 -0800
From: goguen@csl.sri.com
Subject: a mailing on termination of rewriting systems
I think it is undoubtedly a good idea for those who are interested in
termination to exchange ideas. But there is already another relatively narrow
mailing list, namely NARROW@a.cs.uiuc.edu, that I have noticed gets relatively
little traffic (I dont think I've seen a msg for a month now). So mightn't it
make sense to "unify" these two lists? I.e., how about a mailing list on term
rewriting in general? For example, I just wrote a paper on unification for
which I might circulate the abstract to the more general list, although it
doesnt quite fit under either termination or narrowing. Possibly others could
cite similar examples. And arent the chances good that if you're interested
in narrowing, then you are also interested, at least peripherally, in narrowing,
and unification, ans so on?
Cheers,
Joseph
------------------------------------------------------------------------
Date: Thu, 4 Feb 88 09:19:52 est
From: Albert R. Meyer <meyer@THEORY.LCS.MIT.EDU>
Subject: a mailing on termination of rewriting systems
Joe's suggestion sounds sensible to me.
Regards, A.
------------------------------------------------------------------------
Date: Thu, 4 Feb 88 12:50:12 CST
From: reddy@b.cs.uiuc.edu (Uday S. Reddy)
Subject: a mailing on termination of rewriting systems
I support the idea of creating a mailing list to deal with all aspects
of term rewriting (including termination, and possibly unification).
In fact, I am surprised that there isn't one already.
However, the mailing list on narrowing would probably have to exist
separately (at least till we get an idea of the kind of traffic it
will get). The reason is that narrowing has now evolved into a
"programming mechanism" and many people on this list probably do not
share all the interests of term rewriting discipline (e.g. logic
programming, data flow, or graph reduction people).
If a REWRITING list gets created, those people on the NARROW list who
are mainly interested in rewriting aspects (as opposed to programming
language aspects) can move to the REWRITING list. I will repost
articles of common interest between the two groups. Thus, people with
common interests can avoid getting duplicate copies of postings from
different mailing lists.
One of the reasons NARROW list hasn't yet seen much traffic is that,
till very recently, many people were still being added to the list.
So, I discouraged senders to post articles till it reached a steady
state. We should soon be seeing more traffic.
Uday Reddy
------------------------------------------------------------------------
Date: Thu, 4 Feb 88 11:25:31 -0100
From: rana@iesd.uucp
Subject: Joseph's suggestion
is something to be considered seriously. If a mailing list is not very active
then why shouldn't we merge it.
rana@iesd.uucp
------------------------------------------------------------------------
Date: Tue, 09 Feb 88 12:19:26 -0800
From: goguen@csl.sri.com
Subject: mailing lists on narrowing, termination and rewriting
Dear Uday,
I agree with the thrust of your argument that the narrowing list may be of
interest to some people who are not also interested in rewriting, because of
its connections with logic programming. However, I think that this argument
would be much stronger if the focus of your list were a little less narrow.
In particular, why dont you broaden it to include other combinations of
functional and logic programming? Then I would not be able to argue that
NARROW <= REWRITING.
Also, this would (presumably) enlarge the circulation of your list, by making
it making it somewhat braoder and more of a public service.
Cheers,
Joseph
∂17-Feb-88 1543 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Looking for a roommate during the 5th MIT VLSI Conference.
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 88 15:43:42 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Wed 17 Feb 88 15:31:10-PST
Received: by lindy.stanford.edu; Wed, 17 Feb 88 14:46:02 PST
Received: by Forsythe.Stanford.EDU; Wed, 17 Feb 88 14:41:45 PST
Received: by BYUADMIN (Mailer X1.25) id 4002; Wed, 17 Feb 88 15:40:53 MST
Date: Wed, 17 Feb 88 16:22:34 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
akg%cs.purdue.edu@forsythe.stanford.edu
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: akg%cs.purdue.edu@forsythe.stanford.edu
Subject: Looking for a roommate during the 5th MIT VLSI Conference.
To: Local Distribution <aflb.tn@sushi.stanford.edu>
I am looking for a person to share a room during the Fifth MIT
Conference on Advanced Research IN VLSI, March 28 - March 30
to be held in Cambridge, Mass. If you are interested, please contact:
Ajay K Gupta (akg@cs.purdue.edu)
Dept. of Computer Sciences,
Purdue University,
West-Lafayette, IN 47907.
∂17-Feb-88 1626 BSCOTT@Score.Stanford.EDU ONR Young Investigator Announcement
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 88 16:26:43 PST
Date: Wed 17 Feb 88 16:19:34-PST
From: Betty Scott <BSCOTT@Score.Stanford.EDU>
Subject: ONR Young Investigator Announcement
To: Faculty@Score.Stanford.EDU
cc: BScott@Score.Stanford.EDU
Message-ID: <12375559657.13.BSCOTT@Score.Stanford.EDU>
I have a copy of the ONR Young Investigator Program mentioned in today's
Campus Report. Eligibility: This program is open to U.S. citizens holding
tenure-track positions at U.S. universities and colleges who received their
graduate degrees (Ph.D. or equivalent) on or after 1 December 1982. Prefer-
ence will be given to individuals who are not currently principal or co-
principal investigators on an ONR contract.
If anyone would like a copy of this announcement, please let me know.
Betty
-------
∂18-Feb-88 1105 emma@russell.stanford.edu CSLI Calendar, February 18, 1988, 3:18
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 18 Feb 88 11:04:07 PST
Received: from russell.stanford.edu by csli.stanford.edu (3.2/4.7); Thu, 18 Feb 88 10:16:49 PST
Received: by russell.stanford.edu (3.2/4.7); Thu, 18 Feb 88 10:18:05 PST
Date: Thu, 18 Feb 88 10:18:05 PST
From: emma@russell.stanford.edu (Emma Pease)
To: friends@russell.stanford.edu
Subject: CSLI Calendar, February 18, 1988, 3:18
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
18 February 1988 Stanford Vol. 3, No. 18
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 18 February 1988
12 noon TINLunch
Ventura Hall Reading: "The Limits of AI"
Conference Room by J. T. Schwartz
Discussion led by Jerry Hobbs
(hobbs@warbucks.ai.sri.com)
Abstract in last week's Calendar
2:15 p.m. CSLI Seminar
Room G-19 Intelligent, Communicating Agents
Redwood Hall Nils Nilsson
(nilsson@score.stanford.edu)
Abstract in last week's Calendar
3:30 p.m. Tea
Ventura Hall
--------------
CSLI ACTIVITIES FOR NEXT THURSDAY, 25 February 1988
12 noon TINLunch
Ventura Hall Reading: to be announced
Conference Room Discussion led by Annie Zaenen
(zaenen.pa@xerox.com)
Abstract to appear later
2:15 p.m. CSLI Seminar
Room G-19 Implementing a BDI agent
Redwood Hall Robert Moore
(bmoore@ai.sri.com)
Abstract to appear later
3:30 p.m. Tea
Ventura Hall
--------------
∂18-Feb-88 1536 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Change in functioning of Theory Net
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Feb 88 15:36:37 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Thu 18 Feb 88 15:24:32-PST
Received: by lindy.stanford.edu; Thu, 18 Feb 88 11:10:03 PST
Received: by Forsythe.Stanford.EDU; Thu, 18 Feb 88 11:01:52 PST
Received: by BYUADMIN (Mailer X1.25) id 9162; Thu, 18 Feb 88 10:52:15 MST
Date: Thu, 18 Feb 88 11:36:38 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Victor S. Miller" <VICTOR%YKTVMZ.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: "Victor S. Miller" <VICTOR%YKTVMZ.BITNET@forsythe.stanford.edu>
Subject: Change in functioning of Theory Net
To: Local Distribution <aflb.tn@sushi.stanford.edu>
Since its inception, Theory Net has been a moderated list (i.e. all
submissions were first sent to the moderator, currently me). However,
because all of the contributors have been good citizens, we have decided
to experiment with having theory net automatically redistributed.
The proper procedure for making contributions to theory net is to send
your contribution to THEORYNT@NDSUVM1 or THEORYNT@DEARN (both addresses
are on bitnet). The internet addresses are
THEORYNT%NDSUVM1.BITNET@CUNYVM.CUNY.EDU or
THEORYNT%DEARN.BITNET@CUNYVM.CUNY.EDU
where you can use any other gateway to bitnet available to you instead
of cunyvm. Please do not send administrative requests to the whole list!
Routine administrative requests (addition or deletion from the list) should
be directed to LISTSERV@NDSUVM1 or LISTSERV@DEARN. To get added,
the body of the mail should consist of one line like:
SUB THEORYNT Victor S. Miller
Where your name should be in the place of mine. To get deleted
SIGNOFF THEORYNT
Direct any other requests to THEORYNT@YKTVMX (on bitnet) or
TheoryNet-Request@ibm.com
Victor
∂18-Feb-88 1548 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Hash functions
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Feb 88 15:48:16 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Thu 18 Feb 88 15:26:12-PST
Received: by lindy.stanford.edu; Thu, 18 Feb 88 11:12:12 PST
Received: by Forsythe.Stanford.EDU; Thu, 18 Feb 88 11:02:37 PST
Received: by BYUADMIN (Mailer X1.25) id 8690; Thu, 18 Feb 88 10:14:19 MST
Date: Thu, 18 Feb 88 10:51:01 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
ND HECN E-mail Postmaster <INFO%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Resent-From: ND HECN E-mail Postmaster <INFO@NDSUVM1>
Comments: Originally-From: "Pat (Lewis,Pat J)" <LEWIS@GRIN1.Bitnet>
From: ND HECN E-mail Postmaster <INFO%NDSUVM1.BITNET@forsythe.stanford.edu>
Subject: Hash functions
To: Local Distribution <aflb.tn@sushi.stanford.edu>
I found this in our Bit Bucket recently. Please note the name of the list
is Theorynt @ NDSUVM1 . (It is now a normal broadcast list by the way).
If, by chance, I already forwarded this please excuse the duplication. Marty
----------------------------Original message----------------------------
Well, I don't claim to be an expert on the subject, but a linear congruence
would seem to me to be the best approach. Something of the form:
index = (a * key + c) mod m
where m is the table size and a and c are relatively prime to m would
do pretty well. On our system (VAX) I let the modulus operation be handled
by what's left over after arithmetic overflow since overflow doesn't cause
a visible error. So the function can really be written as:
index = a * key + c
as long as a and c are given appropriate values. This is a quick and
efficient method and gives good pseudo-random index values. Hope that
helps.
Pat Lewis
Grinnell College User Consultant
LEWIS@GRIN1.BITNET
∂18-Feb-88 1559 GANGOLLI@Sushi.Stanford.EDU Theory Net Addendum
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Feb 88 15:57:16 PST
Date: Thu 18 Feb 88 15:39:58-PST
From: Anil R. Gangolli <GANGOLLI@Sushi.Stanford.EDU>
Subject: Theory Net Addendum
To: aflb.tn@Sushi.Stanford.EDU
Office Phone: (415) 723-3605
Message-ID: <12375814592.13.GANGOLLI@Sushi.Stanford.EDU>
Those of you who receive this message are getting your theory-net mail
through a local re-distribution list currently administered by me.
These instructions supercede some given by Victor Miller in his recent
message.
If you wish to be removed from the list or change your address, please
send a message (in English) to AFLB-REQUEST@SUSHI.STANFORD.EDU .
Please indicate that you are talking about the theory-net list
and not the regular AFLB mailing list.
--anil. AFLB-REQUEST@SUSHI.STANFORD.EDU
-------
∂18-Feb-88 1726 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Hash functions
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Feb 88 17:26:26 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Thu 18 Feb 88 17:19:26-PST
Received: by lindy.stanford.edu; Thu, 18 Feb 88 17:25:27 PST
Received: by Forsythe.Stanford.EDU; Thu, 18 Feb 88 13:02:08 PST
Received: by BYUADMIN (Mailer X1.25) id 0614; Thu, 18 Feb 88 12:30:24 MST
Date: Thu, 18 Feb 88 13:01:21 cst
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Pat (Lewis,Pat J)" <LEWIS%GRIN1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: "Pat (Lewis,Pat J)" <LEWIS%GRIN1.BITNET@forsythe.stanford.edu>
Subject: Hash functions
To: Local Distribution <aflb.tn@sushi.stanford.edu>
Someone asked about appropriate hash functions for an integer set of keys -
Well, I don't claim to be an expert on the subject, but a linear congruence
would seem to me to be the best approach. Something of the form:
index = (a * key + c) mod m
where m is the table size and a and c are relatively prime to m would
do pretty well. This is a quick and efficient method and gives good
pseudo-random index values. Hope that helps.
Pat Lewis
Grinnell College User Consultant
LEWIS@GRIN1.BITNET
∂18-Feb-88 2348 NAIL-mailer@sail.stanford.edu CFP: 5th Conf. on Data Eng. (Feb 7-9, 1989, Los Angeles)
Received: from navajo.stanford.edu by SAIL.Stanford.EDU with TCP; 18 Feb 88 23:48:06 PST
Received: from Sail.Stanford.EDU by navajo.stanford.edu with TCP; Thu, 18 Feb 88 23:41:13 PST
Date: 18 Feb 88 2003 PST
From: Arthur Keller <ARK@sail.stanford.edu>
Subject: CFP: 5th Conf. on Data Eng. (Feb 7-9, 1989, Los Angeles)
To: arpanet-bboards@ai.ai.mit.edu, nail@sail.stanford.edu,
cs545-people@sri.com
CALL FOR PAPERS
FIFTH INTERNATIONAL CONFERENCE ON DATA ENGINEERING
TITLE:
Fifth International Conference on Data Engineering.
February 7-9, 1989
Los Angeles, California, USA
sponsored by The Computer Society of the IEEE
CONFERENCE TIMETABLE AND INFORMATION:
Papers due: June 15, 1988
Tutorial Proposals Due: June 15, 1988
Acceptance Letter Sent: September 15, 1988
Camera Ready Copy Due: November 1, 1988
Tutorials: February 6 and 10, 1989
Conference: February 7-9, 1989
For further information contact the General Chairperson, John Carlis,
Computer Science Department, University of Minnesota, 207 Church Street
SE, Minneapolis, MN 55455 (612) 625-6092; carlis%umn-cs.arpa@relay.cs.net
SCOPE:
Data Engineering is concerned with the semantics and structuring of data
in information system design, development, management, and use; and with
computer system and architectural considerations that are relevant to
that concern. It encompasses both traditional and emerging issues and
applications. The purpose of this conference is to provide a forum for
the sharing of practical experiences and research advances from an
engineering point of view among those interested in automated data and
knowledge management. Our expectation is that this sharing will enable
future information systems to be more efficient and effective, and future
research to be more relevant and timely.
We are particularly soliciting industrial, business, and government
participation. We know it is vital that there be a dialogue between
practitioners and researchers. We look forward to reports of information
systems experience detailing experiments, evaluation, problems, and
opportunities associated with design, implementation, and operation. Such
reports will be given special consideration.
TOPICS OF INTEREST INCLUDE:
AI and Knowledge Based Systems
Applications and Application Systems
Autonomous Distributed Systems
Communication Systems
Concurrency Control and Data Integrity
Data Access Control and Security
Database Management and Structures
Data Engineering Techniques and Tools
Data Services and Servers
Information System Architecture
Performance Evaluation
User Interfaces
PAPER SUBMISSIONS:
Each paper's length should be limited to 8 proceedings pages, which is
about 5000 words, or 25 double spaced typed pages. Five copies of
completed papers should be mailed before June 15, l988 to:
Richard L. Shuey, Computer Science Department, Rensselaer Polytechnic
Institute, Troy, NY, 12189-3590; (518) 276-8376 or (518) 374-5684;
Shuey%MTS@ITSGW.RPI.EDU or shuey@ge-crd.arpa
TUTORIALS:
The day preceding the conference will be devoted to introductory
tutorials which may provide background for the conference proper. The day
following the conference will be devoted to advanced tutorials. Proposals
for tutorials on Data Engineering topics are welcome. Send proposals by
June 15, 1988 to:
Mohan Ahuja, Department of Computer Science, The Ohio State
University, 2036 Neil Avenue, Columbus, OH 43210-1277; (614)
292-6377; ahuja@ohio-state.arpa
AWARDS, STUDENT PAPERS AND SUBSEQUENT PUBLICATION:
Awards will be given to the best paper and to the best student paper
(denoted as such when submitted solely by students). The latter will
receive the K. S. Fu award honoring one of the early supporters of the
conference. Up to three grants of $500.00 each will be available to help
defray travel costs of student authors. Outstanding papers will be
considered for publication in the IEEE Computer Society publications:
Computer, Expert, Software, and Transactions on Software Engineering,
etc. For more information, contact the general chairman.
∂19-Feb-88 0947 TAJNAI@Score.Stanford.EDU $20K Equipment Grant from H-P
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Feb 88 09:47:00 PST
Date: Fri 19 Feb 88 09:40:00-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: $20K Equipment Grant from H-P
To: faculty@Score.Stanford.EDU
cc: hiller@Score.Stanford.EDU
Message-ID: <12376011208.14.TAJNAI@Score.Stanford.EDU>
Michael McGrath of H-P (408/447-6564) has $20K of equipment grant
available for CSD. He must have it placed by 2/26, so please speak up
if you can use it.
H-P has some exciting new printers; it can be used for plotters and
workstations.
Nils Nilsson is the Forum liaison with Hewlett-Packard.
Carolyn
-------
∂19-Feb-88 0950 LOGMTC-mailer Logic seminar
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 19 Feb 88 09:49:59 PST
Received: by csli.stanford.edu (3.2/4.7); Fri, 19 Feb 88 09:53:08 PST
Date: Fri 19 Feb 88 09:53:07-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: Logic seminar
To: logic@csli.stanford.edu
Message-Id: <572291587.0.SF@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@CSLI.Stanford.EDU>
Speaker: Dr. Susumu Hayashi, Kyoto and Edinburgh
Title: PX: A computational logic (Part II)
Time: Tuesday, Feb. 23, 4:15-5:30 PM
Place: Room 381-T, Math. Bldg. , Stanford
S. Feferman
-------
∂19-Feb-88 1225 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talks
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Feb 88 12:25:24 PST
Date: Thu 18 Feb 88 15:26:44-PST
From: Anil R. Gangolli <GANGOLLI@Sushi.Stanford.EDU>
Subject: Upcoming AFLB Talks
To: aflb.all@Sushi.Stanford.EDU
Office Phone: (415) 723-3605
Message-ID: <12375812183.13.GANGOLLI@Sushi.Stanford.EDU>
PLEASE NOTE:
* The Mar. 3 slot is still open. If you would like to speak,
please contact me (gangolli@sushi.stanford.edu).
* If nobody volunteers for the Mar. 3 slot, we will meet to discuss
recreational and open problems on that date.
THIS WEEK'S TALK:
25-February-1988: Lenore Blum (Mills College & UC Berkeley)
At: 12:30pm, Th, Margaret Jacks Hall (MJH, Bldg. 460), Rm. 352
Computing over the Reals (or any Arbitrary Ring)
Classically, the theory of computation deals with discrete structures
(e.g., the integers or the rationals). Here, foundational issues
(such as what are appropriate models of computation and measures of
complexity) are well understood. One has confidence in a natural and
polynomially invariant theory.
This is far from the case in computing over continuous structures (such
as the reals). To point to a concrete case, the main competing algorithms
for the linear programming problem (e.g., Simplex and Karmakar's algorithm)
are defined and analyzed using incomparable models of computation
and measures of complexity.
I will discuss various issues involved (e.g., the role of the "condition"
of a problem), and a proposed model of computation over an arbitrary
ring R. In this general setting, we get universal machines, normal forms,
R.E. sets, as well as P, NP and NP complete classes. While our theory
reflects the classical over Z (e.g. the computable functions are the
recursive functions) it also reflects the special mathematical character
of the underlying ring R (e.g. complements of Julia sets provide examples
of R.E. undecidable sets over the reals) and provides a natural setting
for studying foundational issues concerning algorithms in numerical analysis.
This is joint work in progress with M. Shub and S. Smale.
-------
∂19-Feb-88 1647 HEMENWAY@Score.Stanford.EDU Sigma Xi Nominations
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Feb 88 16:47:45 PST
Date: Fri 19 Feb 88 16:41:28-PST
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: Sigma Xi Nominations
To: faculty@Score.Stanford.EDU
Message-ID: <12376087933.20.HEMENWAY@Score.Stanford.EDU>
I have just received a packet of material from the Sigma Xi organization
containing forms for nominating potential new members. If you know of
any students whom you would like to nominate for membership, please let
me know and I will forward the necessary forms to you. The forms must
be submitted to the Stanford coordinator by March 10, 1988.
--Sharon
-------
∂19-Feb-88 1720 LOGMTC-mailer logic lunch
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 19 Feb 88 17:20:07 PST
Received: from russell.stanford.edu by csli.stanford.edu (3.2/4.7); Fri, 19 Feb 88 17:23:17 PST
Received: from localhost by russell.stanford.edu (3.2/4.7); Fri, 19 Feb 88 17:24:36 PST
To: logic@russell.stanford.edu
Subject: logic lunch
Date: Fri, 19 Feb 88 17:24:35 PST
From: Jon Barwise <barwise@russell.stanford.edu>
Long lunch on Monday. I have brought in my copy of one volume of the
Bibliogrpahy of Math logic we were talking about for people to look at.
∂21-Feb-88 1054 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu ATT Grant?
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 88 10:54:28 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Sun 21 Feb 88 10:47:51-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA17515; Sun, 21 Feb 88 10:52:59 PST
Date: Sun, 21 Feb 88 10:52:59 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8802211852.AA17515@Tenaya.stanford.edu>
To: reges@score, wheaton@athen
Cc: ac@score
Subject: ATT Grant?
Al Aho called me recently to say that he might be able (again)
to shepherd thru the ATT system a grant request from Stanford
for $50K. (We have done well in the past with these grants---with
ideas from Stuart Reges, Ed Feigenbaum, Vaughan Pratt and others.)
The grant can be used to support ideas promoting education and/or
research---new initiatives, seed money for new projects, etc.
It can be used to purchase equipment and services but cannot
be used to pay Stanford salaries.
Quite probably Stuart will have some ideas for this; maybe George
Wheaton will too. If faculty members have ideas pls send them
to George (wheaton@athena) who will collect them, and then we'll
use some magic process for deciding which one to send to Al. Al
needs about a one-page write-up per idea plus a proposed budget.
-Nils
∂21-Feb-88 1250 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Jean Rogers
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 88 12:50:43 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Sun 21 Feb 88 12:45:14-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA17599; Sun, 21 Feb 88 12:50:20 PST
Date: Sun, 21 Feb 88 12:50:20 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8802212050.AA17599@Tenaya.stanford.edu>
To: ac@score
Subject: Jean Rogers
In line with Department Policy about securing faculty concurrence
in matters concerning our lecturers, I would like to report on
"the Jean Rogers situation."
We have received several negative comments from students about Jean's
teaching. Stuart tells me that these complaints are more than what
might be expected from the occasional disgruntled students of
CS106/108. Some seem to be quite serious, namely that Jean is not
challenging, does not explain concepts well, doesn't go into things
deeply enough and so on.
We need to decide soon whether or not to extend Jean's contract
with us into the next calendar year. (In any case, she will
stay through December of 1988; we need to give her 9 months
notice, I believe.)
I have asked Vaughan Pratt to be a committee of one to advise
me and the faculty about this matter. He has looked over the
complaints, attended some of Jean's lectures, examined the TBP
results and otherwise familiarized himself with the case.
His conclusion is that, giving her the benefit of the doubt,
she is a marginal lecturer---probably not Stanford quality.
In looking at the ug curriculum recently, Don Knuth had occasion to
watch several Rogers video tapes of CS108. His conclusion is that,
although she is good at teaching prolog, she is not teaching computer
science at a quality level we need at Stanford.
We recently asked James Wilson not to continue as a lecturer anymore
for similar reasons. I think our other lecturers, Roy Jones and
Steve Fisher, are much better than James or Jean. They seem to
be above threshold.
Since the Provost granted us special funds to hire lecturers based on
the condition that they be the very best we could find anywhere and
would teach superb courses, I am recommending (with Stuart Reges'
concurrence) that we not rehire Jean Rogers. Before making this
decision "official" however, I would like to hear from the faculty on
the following questions: Is there anyone who thinks we ought to hold a
special faculty meeting to discuss this topic? Is there anyone who
would like to look through the Rogers file to acquaint themselves with
the details of the case. Barring hearing from anyone on these
matters, I will assume that I have discharged my obligation to seek
faculty guidance and will inform Jean of our intention not to rehire
her.
-Nils
∂22-Feb-88 0216 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1@forsythe.stanford.edu Re: Looking for a roommate during the 5th MIT VLSI Conference.
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Feb 88 02:16:12 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Mon 22 Feb 88 02:09:48-PST
Received: by lindy.stanford.edu; Mon, 22 Feb 88 02:16:18 PST
Received: by Forsythe.Stanford.EDU; Mon, 22 Feb 88 02:14:08 PST
Received: by BYUADMIN (Mailer X1.25) id 6354; Mon, 22 Feb 88 03:13:58 MST
Date: Sun, 21 Feb 88 22:15:01 EST
Reply-To: TheoryNet List <THEORYNT@ndsuvm1>,
Kent Paul Dolan <kent%xanth.cs.odu.edu@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT@ndsuvm1>
From: Kent Paul Dolan <kent%xanth.cs.odu.edu@forsythe.stanford.edu>
Subject: Re: Looking for a roommate during the 5th MIT VLSI Conference.
To: Local Distribution <aflb.tn@sushi.stanford.edu>
In-Reply-To: <8802172244.AA23524@jade.berkeley.edu>
In article <8802172244.AA23524@jade.berkeley.edu> you write:
>I am looking for a person to share a room during the Fifth MIT
>Conference on Advanced Research IN VLSI, March 28 - March 30
>to be held in Cambridge, Mass. If you are interested, please contact:
>
>Ajay K Gupta (akg@cs.purdue.edu)
>
>Dept. of Computer Sciences,
>Purdue University,
>West-Lafayette, IN 47907.
I can't tell you what a surprise it was to see that name, and then
that address; I expect that Gupta must be a fairly common Indian name,
but Ajay Gupta is our system administrator for our VAX/Sun-net system
here! Drop him a note! (ajay@xanth.cs.odu.edu).
Kent, the man from xanth.
∂22-Feb-88 0945 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1@forsythe.stanford.edu equational logic, rewriting techniques, and applications
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Feb 88 09:44:55 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Mon 22 Feb 88 09:37:21-PST
Received: by lindy.stanford.edu; Mon, 22 Feb 88 09:43:59 PST
Received: by Forsythe.Stanford.EDU; Mon, 22 Feb 88 09:42:10 PST
Received: by BYUADMIN (Mailer X1.25) id 0403; Mon, 22 Feb 88 10:39:55 MST
Date: Mon, 22 Feb 88 11:15:05 CST
Reply-To: TheoryNet List <THEORYNT@ndsuvm1>,
lescanne%poincare.crin.fr@forsythe.stanford.edu
Sender: TheoryNet List <THEORYNT@ndsuvm1>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: lescanne%poincare.crin.fr@forsythe.stanford.edu
Subject: equational logic, rewriting techniques, and applications
To: Local Distribution <aflb.tn@sushi.stanford.edu>
----------------------------------------------------------------------------
| A mailing list on equational logic, rewriting techniques and applications.|
----------------------------------------------------------------------------
A call was done recently for a mailing list on termination of
rewriting systems and many people suggested me to extend this to a
broader scope. In addition Gert Smolka who moderated a list on
unification accepted a proposition for merging this list with the new
one.
The new list will be nicknamed "rewriting", but may cover fields like
- equational logics, equational theories including universal
algebra, order-sorted algebras,
- unification, matching in equational theories including narrowing,
- rewriting techniques including completion procedures and
termination,
- congruence closure,
- conditional rewriting,
- rewriting in specific theories including Thue systems and
Grobner bases.
This list is obviously not exhaustive and this may also include aspects
related to applications like lambda-calculus, abstract data types and
software implementation.
The mail may contain informations on new results and new papers, lists
of open problems, question to the community, announcements, discussion
on terminology etc. It will be moderated by one of us at Nancy.
The mailing address will be
rewriting@crin.crin.fr
---- Pierre LESCANNE ----- ------Isabelle GNAEDIG -----
lescanne@poincare.crin.fr gnaedig@prouve.crin.fr
------------------------------------------------------------------------
From: lescanne@poincare.crin.fr
Date: Fri, 19 Feb 88 12:25:26 PST
Subject: First contribution
>From Toyama
We completely proved the following conjecture:
The direct sum of R0 and R1 is left-linear and complete
(complete=confluent+terminating) iff R0 and R1 are so.
This conjecture was first proposed by Klop and Barendregt in their private
communication on January 19, 1986 as the proposition without complete
proof. Against our expectation, the complete proof is not easy. Now we
are preparing for submitting the paper:
Y.Toyama, J.W.Klop, H.P.Barendregt "Termination for the Direct Sum of
Left-linear Term Rewriting Systems".
---------
Toyama : toyama%ntt-20.ntt.jp@relay.cs.net
--------------------------------------------------------------
>From P. Lescanne
A first task could be to list open problems. Send me those you feel
interesting. They could be small or important. Here is a first list.
A LIST OF OPEN PROBLEMS IN TERMINATION OF REWRITING SYSTEMS
-----------------------------------------------------------
1. Reduction orderings that can be extended to total orderings on
ground terms play a main role in the unfailing completion procedure.
It is said that polynomial ordering satisfy this requirement.
Obviously this is not the case for the ordering on T(,f,g-,X) with
[[f]] = [[g]]. What are the conditions? How the extension is done?
2. The fact that a polynomial ordering is used imposes a restriction
on the complexity of the computation of the normal form, which has to
be in exponential time w.r.t. the size of the initial term. Can
someone provide a proof of this fact?
3. Methods based on extension of the recursive path ordering to the
proofs of termination of associative commutative rewriting systems
impose severe restrictions on the systems that can be proved to
terminated. Is it possible to extend these methods to handle the
termination of systems like:
0 + x --> x
s(x) + y --> s(x + y)
0 . x --> 0
s(x) . y --> (x . y) + y
x . (y + z) --> (x . y) + (x . z)
where + and . are both AC? Ahlem Ben Cherifa and Pierre Lescanne propose a
automated proof based on polynomial interpretations for this system in
their SCP paper.
PUBLICATIONS OF TERMINATION AT NANCY
------------------------------------
ON THE RECURSIVE DECOMPOSITION ORDERING WITH LEXICOGRAPHICAL STATUS
AND OTHER RELATED ORDERINGS
by P. Lescanne (CRIN)
Abstract:
--------
This paper study three orderings, useful in theorem proving, especially
for proving termination of term rewriting systems: the
recursive decomposition ordering with status, the recursive path
ordering with status and the closure ordering. It proves the
transitivity of the recursive path ordering, the strict inclusion of
the recursive path ordering in the recursive decomposition ordering,
the totality of the recursive path ordering -- therefore of the recursive
decomposition ordering --, the strict inclusion of the recursive
decomposition ordering in the closure ordering and the stability of
the closure ordering by instanciation.
---------------------------------------------------------------------------
TERMINATION PROOFS BASED ON TRANSFORMATION TECHNIQUES
by Francoise Bellegarde and Pierre Lescanne
Abstract:
---------
A method for proving termination of rewriting systems based on transformation
techniques is described. We define an ordering called transformation ordering
which is useful for proving termination of rewriting systems. A transformation
ordering is defined using two relations: a relation which transforms terms and
a relation which ensures the well-foundedness of the ordering. A property
between these two relations called cooperation is required. Cooperation is
similar to confluence and thus may be localized. Therefore, if relations are
rewrite relations, it is possible to decide the cooperation by looking at
critical pairs. Transformation orderings prove the termination of rewriting
systems that cannot be proved by simplification orderings.
===========================================================================
TERMINOLOGY
Here a list of name for concepts the terminology of which could be discussed.
- an ordering is "monotonic". Usually one says that a function is
monotonic with respect to a congruence.
- a rewriting system is "complete". There are so many uses of
"complete" in mathematical logic. Cannot we prefer "canonical" or
"convergent"?
- An equation is something one tries to solve, an identity is an
axiom presented as an equation. This distinction is clear in "L.
Henkin, The Logic of Equality, The American mathematical Monthly,
1977, vol.84 , pp 597-612". Thus should we say "identitary rewriting"?
∂22-Feb-88 1027 LOGMTC-mailer Talk on Thursday
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Feb 88 10:27:20 PST
Date: Mon 22 Feb 88 10:20:31-PST
From: Anil R. Gangolli <GANGOLLI@Sushi.Stanford.EDU>
Subject: Talk on Thursday
To: logmtc@Sail.Stanford.EDU
Office Phone: (415) 723-3605
Message-ID: <12376805014.14.GANGOLLI@Sushi.Stanford.EDU>
This week's AFLB talk may be of interest to recipients on this list. Abstract
follows. --anil.
25-February-1988: Lenore Blum (Mills College & UC Berkeley)
At: 12:30pm, Th, Margaret Jacks Hall (MJH, Bldg. 460), Rm. 352
Computing over the Reals (or any Arbitrary Ring)
Classically, the theory of computation deals with discrete structures
(e.g., the integers or the rationals). Here, foundational issues
(such as what are appropriate models of computation and measures of
complexity) are well understood. One has confidence in a natural and
polynomially invariant theory.
This is far from the case in computing over continuous structures (such
as the reals). To point to a concrete case, the main competing algorithms
for the linear programming problem (e.g., Simplex and Karmakar's algorithm)
are defined and analyzed using incomparable models of computation
and measures of complexity.
I will discuss various issues involved (e.g., the role of the "condition"
of a problem), and a proposed model of computation over an arbitrary
ring R. In this general setting, we get universal machines, normal forms,
R.E. sets, as well as P, NP and NP complete classes. While our theory
reflects the classical over Z (e.g. the computable functions are the
recursive functions) it also reflects the special mathematical character
of the underlying ring R (e.g. complements of Julia sets provide examples
of R.E. undecidable sets over the reals) and provides a natural setting
for studying foundational issues concerning algorithms in numerical analysis.
This is joint work in progress with M. Shub and S. Smale.
-------
∂22-Feb-88 1045 BSCOTT@Score.Stanford.EDU Tuesday Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Feb 88 10:45:25 PST
Date: Mon 22 Feb 88 10:37:30-PST
From: Betty Scott <BSCOTT@Score.Stanford.EDU>
Subject: Tuesday Lunch
To: Faculty@Score.Stanford.EDU
cc: BScott@Score.Stanford.EDU
Message-ID: <12376808108.30.BSCOTT@Score.Stanford.EDU>
Robert Byer and Pat Devaney will join the faculty at lunch tomorrow to
discuss intellectual property issues and to collect CS faculty views on
the evolution of Stanford's copyright policy as it applies to computer
software.
Background materials were placed in MJH faculty mailboxes this morning. A
few copies will be available at lunch tomorrow.
Betty
-------
∂22-Feb-88 1435 TAJNAI@Score.Stanford.EDU Query from Kay Magleby
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Feb 88 14:35:12 PST
Date: Mon 22 Feb 88 14:26:45-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Query from Kay Magleby
To: faculty@Score.Stanford.EDU
cc: hiller@Score.Stanford.EDU
Message-ID: <12376849840.22.TAJNAI@Score.Stanford.EDU>
Both Jane Evans of Hewlett-Packard and Kay Magleby, formerly of H-P,
have called me re
text editing program TIDE which was offered through the
H-P 200A users group. They are looking for description or
documentation.
If you can help, please call Magleby at 941-3673 oor
Jane Evans at 857-7519.
Carolyn
-------
∂22-Feb-88 1700 HEMENWAY@Score.Stanford.EDU Reminder of Round 1 Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Feb 88 17:00:31 PST
Date: Mon 22 Feb 88 16:53:26-PST
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: Reminder of Round 1 Meeting
To: phd-adm@Score.Stanford.EDU
Message-ID: <12376876543.52.HEMENWAY@Score.Stanford.EDU>
This is just a reminder of tomorrow's (Tuesday, Feb. 23)
meeting...2:30 pm in MJH 252. Hopefully we won't run too long into
the dinner hour but we will have some goodies to quiet those growling
stomachs in any case.
I'll see you all tomorrow.
--Sharon
-------
∂23-Feb-88 1206 ullman@navajo.stanford.edu documents offered
Received: from navajo.stanford.edu by SAIL.Stanford.EDU with TCP; 23 Feb 88 12:06:44 PST
Received: by navajo.stanford.edu; Tue, 23 Feb 88 11:49:20 PST
Date: Tue, 23 Feb 88 11:49:20 PST
From: Jeff Ullman <ullman@navajo.stanford.edu>
Subject: documents offered
To: nail@navajo.stanford.edu
Cc: rfn@sail.stanford.edu
1. I offer copies of CH. 11 (first chapter of VOl. II) of my revised
DB/KB book. This is the chapter on code optimization,
incorporating the old CH. 8 and the first part of CH. 12, as well
as some new material on query opt. for DBMS's (not KBMS's).
If you'd like a copy, send email to Rosemary Napier, rfn@sail.stanford.edu
2. I offer an updated "manual" for the ICODE that incorporates two
extensions:
a) There is now full arithmetic capability, with statements of the form
x := <arith. exp>
e.g., a := b*(c+d/e)-f
b) There is an initial statement, initial(R,<tuple list>),
e.g., initial(par, ((cain, eve), (cain, adam))) to set a
relation R to a particular set of tuples. This may easily be the
best way to initialize a relation, i.e., write one ICODE statement
and run it, rather than entering sqlcmd and inserting the
tuples one-at-a-time.
Again, ask rfn@sail.stanford.edu if you would like a copy.
---jdu
∂23-Feb-88 1308 X3J13-mailer Re: voting
Received: from mitre.arpa by SAIL.Stanford.EDU with TCP; 23 Feb 88 13:06:28 PST
Full-Name: Jim Antonisse
Message-Id: <8802232059.AA18904@mitre.arpa>
Organization: The MITRE Corp., Washington, D.C.
To: MATHIS@A.ISI.EDU
Cc: x3j13@SAIL.STANFORD.EDU, jima@mitre.arpa
Subject: Re: voting
In-Reply-To: Your message of 26 Jan 88 14:06:00 -0500.
<[A.ISI.EDU]26-Jan-88 14:06:48.MATHIS>
Date: Tue, 23 Feb 88 15:59:23 EST
From: jima@mitre.arpa
Bob,
Where exactly *is* the March X3j13 meeting? Does anyone
have details of location, registration fee, etc., figured
out yet? I'll be travelling for the week before it so I'd
like to make all arrangements soon.
Thanks,
Jim Antonisse
MITRE
∂23-Feb-88 1518 STAGER@Score.Stanford.EDU Tau Beta Pi survey forms
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Feb 88 15:18:23 PST
Date: Tue 23 Feb 88 15:11:19-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: Tau Beta Pi survey forms
To: instructors@Score.Stanford.EDU
cc: jimenez@Score.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12377120096.26.STAGER@Score.Stanford.EDU>
Tau Beta Pi course evaluation forms have arrived and are ready for pickup
from Tina Jimenez in CS-TAC. Tina has forms, pencils, instruction sheets,
and return envelopes. Please stop by, or send your TA, to see Tina
sometime soon.
Thanks again for your cooperation.
Claire
-------
∂23-Feb-88 1541 X3J13-mailer voting
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Feb 88 15:37:54 PST
Received: by labrea.Stanford.EDU; Tue, 23 Feb 88 14:57:40 PST
Received: from sunvalleymall.lucid.com by edsel id AA17257g; Tue, 23 Feb 88 14:09:49 PST
Received: by sunvalleymall id AA15130g; Tue, 23 Feb 88 14:15:41 PST
Date: Tue, 23 Feb 88 14:15:41 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8802232215.AA15130@sunvalleymall.lucid.com>
To: jima@mitre.arpa
Cc: MATHIS@a.isi.edu, x3j13@sail.stanford.edu, jima@mitre.arpa,
edsel!jlz@labrea.Stanford.EDU
In-Reply-To: jima@mitre.arpa's message of Tue, 23 Feb 88 15:59:23 EST <8802232059.AA18904@mitre.arpa>
Subject: voting
I sent the original message on December 14 but it looks like it's time for
a reminder. Agenda, subcommitte meeting (that I have arranged) and voting
list to follow later this week.
---jan---
X3J13 Meeting and Subcommitte meetings
3/14/88 - 3/18/88
Palo Alto, CA
The next meeting of X3J13 will be held from 9:00am, Wednesday, March 16,
1988 until 5:00pm, Thursday, March 17, 1988, at the Hyatt Rickeys in Palo
Alto, CA. The meeting will be held in the Executive Conference Room.
Subcommittee meetings will be held Monday, March 14, Tuesday, March 15 and
Friday, March 18.
Please let me know if and when your subcommittee will be meeting in Palo
Alto in March. I need to reserve small rooms now if they're necessary. In
the interest of saving money, if you have a subcommittee member who is local
perhaps the meeting could be held at their company.
For example: the CLOS subcommittee will meet at Lucid
Monday, 3/14 and Tuesday 3/15 at 10:00. Friday's time is
yet to be determined.
A block of rooms is available at the Hyatt Rickeys. The rate will be $84 a
night (plus tax). A limited number of rooms are available for non-smokers.
Please call (800) 228-9000 or (415) 493-8000 before February 26 to receive
the discounted rate. Be sure to mention "X3J13 Standards Committee".
Before I call and get special airline fares I'd like to know if anyone has
found this to be useful. If I get no replies I'll assume it's not necessary
to set up special fares.
Refreshments will be available during the morning (8:00am) and afternoon
sessions. Lunch will be available Wednesday, March 16 and Thursday, March
17. If you have dietary restrictions please complete the appropriate
section below.
The cost per person for food service and conference room rental is $55.00.
Please include a check for this amount, payable to Lucid, with the
registration form.
I will be happy to arrange a group dinner for Wednesday, March 16. Someone
has suggested we go to Watercourse Way in Palo Alto for sushi dinner and go
hot tubbing afterwards at (combined fee of around $25) If interested, please
note this in the appropriate space below.
N San Francisco Airport
W E |
S | | 101
------------------------------------------92
| |
| |
| |
| |
| | 101
Foothills | | San Francisco Bay
| |
| |
|X Hyatt Rickeys |
| |
|El Camino Real |
| |
Los Altos ----------------------------------------San Antonio Road
| |
| |
San Jose Airport
!
Directions from San Francisco airport to Hyatt Rickeys: Take 101 south to
San Antonio Road (about 25 minutes in non-rush hour traffic). Take San
Antonio Road exit marked Los Altos, heading toward the hills. Turn right
on El Camino Real. The hotel is on the right at 4219 El Camino Real, Palo
Alto, CA 94306 (415) 493-8000. Hertz, Avis and National car rentals are
within 1 block.
Directions from San Jose airport: Take 101 north to San Antonio Road (about
15 minutes in non-rushhour traffic). Take San Antonio Road exit marked Los
Altos, heading toward the hills. Turn right on El Camino Real. The hotel
is on the right at 4219 El Camino Real, Palo Alto, CA 94306 (415) 493-8000.
A shuttle service is available though Airport Connection for $12.00.
Pickup points are located directly outside each terminal baggage claim area
at the center traffic island. Shuttle will stop at each blue striped
pillar. The shuttle stops in Menlo Park, Standford and then Hyatt Rickeys.
The schedule from San Francisco Airport to Palo Alto follows:
* *
LV Menlo Stan- Palo Sunny- San ARR
SFO Park ford Alto vale Jose SJC
7:01A 7:20A 7:35A 7:40A 8:00A 8:25A 8:30A Daily
8:16A 8:40A 8:50A 8:55A 9:20A 9:40A 9:45A Ex. Sat
9:11A 9:35A 9:42A 9:46A 10:05A 10:30A 10:35A Daily
11:00A 11:25A 11:30A 11:35A 12:01P 12:25P 12:30P Ex. Sat
12:01P 12:25P 12:30P 12:35P 1:00P 1:25P 1:30P Daily
1:00P 1:25P 1:30P 1:35P 2:00P 2:25P 2:30P Ex. Sat
2:01P 2:30P 2:35P 2:40P 3:10P 3:40P 3:45P Daily
3:06P 3:35P 3:40P 3:45P 4:10P 4:40P 4:45P Ex. Sat
4:01P 4:30P 4:35P 4:40P 5:05P 5:35P 5:40P Daily
5:20P 5:50P 5:55P 6:00P 6:25P 6:50P 6:55P Ex. Sat
6:50P 7:20P 7:25P 7:30P 7:50P 8:15P 8:20P Daily
8:40P 9:05P 9:10P 9:15P 9:40P 10:00P 10:10P Ex. Sat
10:10P 10:40P 10:45P 10:50P 11:15P 11:35P 11:45P Daily
Shuttle service from Palo Alto to San Francisco Airport:
* *
LV SJC Sunny- Palo Stan- Menlo AR
San Jose vale Alto ford Park SFO
5:25A 5:30A 5:40A 6:08A 6:22A 6:27A 7:00A Daily
6:15A 6:20A 6:35A 7:08A 7:25A 7:30A 8:15A Ex. Sat
7:25A 7:30A 7:45A 8:13A 8:32A 8:37A 9:10A Daily
8:25A 8:30A 8:45A 9:13A 9:32A 9:37A 10:10A Ex. Sat
9:40A 9:45A 9:55A 10:23A 10:37A 10:42A 11:15A Daily
10:30A 10:35A 10:45A 11:08A 11:22A 11:27A 12:05P Ex. Sat
12:25P 12:30P 12:40P 1:08P 1:22P 1:27P 2:00P Daily
1:25P 1:30P 1:40P 2:08P 2:22P 2:27P 3:05P Ex. Sat
2:25P 2:30P 2:40P 3:08P 3:22P 3:27P 4:00P Daily
3:40P 3:45P 3:55P 4:25P 4:44P 4:49P 5:19P Ex. Sat
4:55P 5:00P 5:15P 5:45P 6:05P 6:10P 6:40P Daily
6:50P 6:55P 7:05P 7:30P 7:45P 7:50P 8:20P Ex. Sat
8:15P 8:20P 8:30P 8:55P 9:10P 9:15P 9:45P Daily
Feel free to contact me if you have any questions.
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
edsel!jlz@labrea.stanford.edu
(415) 329-8400
!
X3J13 March Meeting Registration Form
Please include check for $55.00 payable to Lucid mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
*Feel free to bring check to meeting but please let me know if you will be
attending.
!
Name: _____________________________________________________________
Institution: ______________________________________________________
Street Address: ___________________________________________________
City: ________________ State: ___ Phone: ________________________
Net-Address: ______________________________________________________
Lunch 3/18: yes _______ no _______
Lunch 3/17: yes _______ no _______
Dietary Restrictions:_______________________________________________
Sushi Dinner 3/16: yes ______ something else ______
Hot tubbing 3/16: yes ______ something else ______
Set up special airline fares: yes _______ no _______
Subcommittee Name: _________________________________________________
Subcommittee Chair: ________________________________________________
____ We need a meeting room
____ We will be meeting at _________________________________________
∂23-Feb-88 1551 emma@russell.stanford.edu CSLI late announcement
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 23 Feb 88 15:51:28 PST
Received: from russell.stanford.edu by csli.stanford.edu (3.2/4.7); Tue, 23 Feb 88 13:13:42 PST
Received: by russell.stanford.edu (3.2/4.7); Tue, 23 Feb 88 13:15:03 PST
Date: Tue, 23 Feb 88 13:15:03 PST
From: emma@russell.stanford.edu (Emma Pease)
To: friends@russell.stanford.edu
Subject: CSLI late announcement
Below are the titles and abstracts for the TINLunch and Seminar to be
held this week.
CSLI TINLUNCH
Reading: "Babe Ruth Homered his Way into the Hearts of America"
by Ray Jackendoff, Brandeis University
Discussion led by Annie Zaenen
noon, February 25
Ventura Hall
This paper is concerned with the mapping between syntactic structure
and semantic/conceptual structure. When the one doesn't reflect the
other in a direct way, one can either complicate the syntactic
structure (e.g., by assuming a deep structure that would reflect the
conceptual structure more directly) or one can complicate the
correspondence rules. Jackendoff starts from his own specific
assumptions about the conceptual structure (elaborated in his book
Semantics and Cognition (MIT press 1983) and his paper "The status of
thematic roles in linguistic theory" (LI,1987)) and discusses one case
in which the syntax/semantics mapping is not direct; the one
exemplified in sentences like `Babe Ruth homered his way into the
hearts of America.' He concludes that a syntactic solution to the
problem is not appealing but that one has either to claim that one has
a kind of idiom or that the correspondence rules have to be
complicated. The issue addressed arises of course in all theories
trying to spell out the syntax semantics mapping; the assumptions made
here are different in their specifics from those that most of us would
make but are stated in a notation that is rather close to a attribute
value representation and they argue for a `surfacey' syntax , at least
in this case, so i hope they are sufficiently close to inspire people
to think about their own approaches to this and similar problems
CSLI SEMINAR
Implementing a BDI Agent
Robert C. Moore
2:15, February 25
Redwood G-19
The BDI (Belief-Desire-Intention) model of rational agency is a
familiar one around CSLI, having been the focus of the RATAG project
for about three years. As part of the ICA (Intelligent, Communicating
Agents) project, we are attempting to do a complete implementation of
an agent based on the BDI model. As always, implementation forces us
to confront issues that we had previously overlooked. This talk will
focus on a number of those issues including:
a formal semantics for desire that can be used to motivate action;
extending the notion of dependency-directed belief revision ("truth
maintenance") to include the dependency of intentions on desires and
beliefs and the dependency of beliefs on intentions;
combining inference and planning by treating intentions as "assumable"
propositions that one encounters in trying to infer that one's beliefs
will be satisfied.
∂23-Feb-88 1736 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu retreat
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Feb 88 17:36:42 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 23 Feb 88 17:30:47-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA00978; Tue, 23 Feb 88 17:36:27 PST
Date: Tue, 23 Feb 88 17:36:27 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8802240136.AA00978@Tenaya.stanford.edu>
To: ac@score
Subject: retreat
It has been suggested that the CSD (with CSL) hold a "retreat" to
enable all of us to find out what each other is doing. At this
retreat we would not schedule discussion of political, administrative,
strategic matters. It would be strictly technical.
I'd be interested to know how the faculty feel about such a retreat.
Is it a good idea? Would you attend? Should (some/all) Research
Associates attend? Should any students attend? How about
having it over a weekend (Fri evening thru Sunday noon, say)?
Should spouses/friends be invited if a Sat. night dinner is
included?
To be able to have this retreat during Spring Quarter, I'll have to
get busy and schedule a date and place soon. Although suggestions
about dates and places will probably vary all over the place, don't
hesitate to send ideas on that if you want.
-Nils
∂24-Feb-88 0856 HEMENWAY@Score.Stanford.EDU Round 2 Schedule
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 08:56:49 PST
Date: Wed 24 Feb 88 08:50:55-PST
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: Round 2 Schedule
To: phd-adm@Score.Stanford.EDU
Message-ID: <12377312991.20.HEMENWAY@Score.Stanford.EDU>
Thank you for all of your hard work on Round 1. Two more weeks and it
will all be over!
Below is the schedule of readings for Round 2. The entries in the table
are rater numbers.
Pickup day Batch "A" Batch "B" Batch "C"
__________________________________________________________
Wednesday, 2/24 10 2 6 2=Hennessy
Thurs., 2/25 4 9 3 3=Manna
Friday, 2/26 7 8 11 4=Gupta
Sat., 2/27 3 10 7 5=Gabriel
Sunday, 2/28 6 4 9 6=Goldberg
Monday, 2/29 11 6 8 7=Wiederhold
Tuesday, 3/1 2 7 4 8=Rosenschein
Wednesday, 3/2 9 3 10 9=Blatt
Thurs., 3/3 8 11 2 10=Chambers
11=Pieper
The groundrules are as follows:
(1) Pick up the folders from your predecessor. The first batches will
be ready after 4:00 pm today (for Craig, John and Andy) in Lynn's
office.
(2) Give the folders to your successor. If you would prefer to drop
your batch off with me (rather than passing it directly off to the
next reader) please make sure that the next reader knows that.
(3) Hand in your rating sheets to me as soon as you finish the batch.
The completed rating sheets should not be passed on to the next
reader.
(4) Please turn in the last batch (Stan, Karen and John) to me as
early as possible on Friday, March 4.
The Round 2 meeting will be at 2:30 on Tuesday, March 8 (hopefully in
MJH 252 but I have to negotiate). "Super Tuesday" seems an
appropriate designation!
Please let me know right away if any problems develop with the
schedule. Many thanks.
--Sharon
-------
∂24-Feb-88 0934 GENESERETH@Score.Stanford.EDU Re: retreat
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 09:34:38 PST
Date: Wed 24 Feb 88 09:30:04-PST
From: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Subject: Re: retreat
To: nilsson@Tenaya.Stanford.EDU
cc: ac@Score.Stanford.EDU
In-Reply-To: <8802240136.AA00978@Tenaya.stanford.edu>
Message-ID: <12377320118.11.GENESERETH@Score.Stanford.EDU>
Nils,
Well, as you know I am a striong supporter of technical communication
among different parts of the department. I vote YES.
Of course the ida is not without difficulty. It is very easy for
someone to present his owrk in too much detail, without sufficient
motive and/or background that we all get bored or fail to see the
point or, worse, decide the work is misguided. In order to make
it valuable, it will require that everyone make an active effort
to communicate (at the level that we would communicate with, say,
a visting committee) and that the organization be good. Do you have
the time to organize this now?
mrg
-------
∂24-Feb-88 0942 TAJNAI@Score.Stanford.EDU Computer Forum Annual Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 09:42:37 PST
Date: Wed 24 Feb 88 09:37:14-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Computer Forum Annual Meeting
To: faculty@Score.Stanford.EDU
cc: hiller@Score.Stanford.EDU
Message-ID: <12377321424.17.TAJNAI@Score.Stanford.EDU>
Thank you all for your support in making the 20th Annual Meeting the
best ever.
If you did not receive a packet and gift, please let me know.
Carolyn
-------
∂24-Feb-88 0955 TAJNAI@Score.Stanford.EDU Dates for 1989 Computer Forum
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 09:55:15 PST
Date: Wed 24 Feb 88 09:50:04-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Dates for 1989 Computer Forum
To: faculty@Score.Stanford.EDU
cc: hiller@Score.Stanford.EDU
Message-ID: <12377323760.17.TAJNAI@Score.Stanford.EDU>
Dates have been set for the 21st Annual Meeting of the
Computer Forum.
Preliminary Activities: Tuesday, February 14, 1989
Conference: Wednesday/Thursday, February 15/16, 1989
Mark your calendars!
Carolyn
-------
∂24-Feb-88 1139 X3J13-mailer Subcommittee meetings
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 11:39:37 PST
Received: by labrea.Stanford.EDU; Wed, 24 Feb 88 11:01:07 PST
Received: from sunvalleymall.lucid.com by edsel id AA21628g; Wed, 24 Feb 88 10:25:19 PST
Received: by sunvalleymall id AA16953g; Wed, 24 Feb 88 10:31:18 PST
Date: Wed, 24 Feb 88 10:31:18 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8802241831.AA16953@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: Subcommittee meetings
Here are the ones I know about.
---jan---
Monday, 3/14
9:00 -
9:30 -
10:00 - CLOS
10:30 - Gabriel
11:00 - Lucid
11:30 - |
12:00 - |
12:30 - |
1:00 - | Characher
1:30 - | Linden
2:00 - | Hyatt Iteration
2:30 - | Delmonte Room White
3:00 - | | Hyatt
3:30 - | | Regency Room
4:00 - | - |
4:30 - | |
5:00 - - -
5:30 -
6:00 -
Tuesday, 3/15
9:00 - Character Clean-up
9:30 - Linden Masinter
10:00 - Hyatt | CLOS
10:30 - Delmonte Room | Gabriel
11:00 - | | Lucid
11:30 - | | |
12:00 - | - |
12:30 - | |
1:00 - | Editorial |
1:30 - | Chapman |
2:00 - | Lucid |
2:30 - | | |
3:00 - | - |
3:30 - | |
4:00 - - |
4:30 - |
5:00 - -
5:30 -
6:00 -
Friday, 3/18
9:00 -
9:30 -
10:00 -
10:30 -
11:00 -
11:30 -
12:00 -
12:30 -
1:00 -
1:30 -
2:00 -
2:30 -
3:00 -
3:30 -
4:00 -
4:30 -
5:00 -
5:30 -
6:00 -
∂24-Feb-88 1139 X3J13-mailer X3J13 committee meeting agenda draft
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 11:39:49 PST
Received: by labrea.Stanford.EDU; Wed, 24 Feb 88 11:01:24 PST
Received: from sunvalleymall.lucid.com by edsel id AA21834g; Wed, 24 Feb 88 10:49:37 PST
Received: by sunvalleymall id AA17034g; Wed, 24 Feb 88 10:55:36 PST
Date: Wed, 24 Feb 88 10:55:36 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8802241855.AA17034@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: X3J13 committee meeting agenda draft
DRAFT
X3J13 Committee Meeting Agenda
March 16 - 17, 1988
1 Call to Order, March 16, 9:00am
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis
- Introduction of attendees
- Report on ISO meeting, Dick Gabriel
- Future meetings and mailings, Jan Zubkoff
3 Approval of Agenda
4 Approval of Minutes
5 CLOS (Doc: 88-002, 88-003, 88-004), Dick Gabriel, Danny Bobrow, et.al.
6 Lunch, 12:00pm - 1:00pm
7 CLOS continuation
8 Recess, 5:00pm
9 Call to Order, March 17, 9:00am
10 Clean-up, Larry Masinter
11 Lunch
12 Status of Standard, Kathy Chapman; 1 hour
13 Function Specs, JonL White, Steve Haflich, Bob Kearns; 20 minutes
14 Condition System, Kent Pitman; 1 hour
15 Other committee reports
16 Adjournment, 5:00pm
∂24-Feb-88 1140 X3J13-mailer voting at X3J13
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 11:40:23 PST
Received: by labrea.Stanford.EDU; Wed, 24 Feb 88 11:01:55 PST
Received: from sunvalleymall.lucid.com by edsel id AA22000g; Wed, 24 Feb 88 11:07:43 PST
Received: by sunvalleymall id AA17093g; Wed, 24 Feb 88 11:12:40 PST
Date: Wed, 24 Feb 88 11:12:40 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8802241912.AA17093@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: voting at X3J13
X3J13 VOTING LIST for March 1988 meeting
Bob's records indicate these groups were represented at the
indicated meetings. If they have paid their X3 service fees,
they can vote at the meeting in Palo Alto.
Company Name Cambridge Ft. Collins
-----------------------------------------------------------
A.I. Architectures x
Aerospace x
Alliant x
Bath U. x x
CSC x
DEC x x
Edinbrugh U. x x
Encore x
Evans and Sutherland x
Franz x x
Gensym x
Gigamos x x
GMD x
Goldhill x x
Gould x
Grumman x x
Hewlett Packard x x
Honeywell x x
IBM x x
ILOG S.A. x
INRIA x
Internat. Lisp Assoc. x
Johnson Controls x x
Lucid x x
Mathis x x
MCC x x
Micro. Sys. Consultants x
MIT x
Mitre x x
NBS x
Prime x
Red Shark Software x
Schlumberger x
Sun x
Symbolics x x
Tektronics x x
Texas Instruments x x
Thinking Machines x x
Unisys x x
USC-ISI x
Wang x
Xerox x x
∂24-Feb-88 1343 @Score.Stanford.EDU:CHEQUER@Sierra.Stanford.EDU SITN announcement/Andy DiPaolo
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 13:43:11 PST
Received: from Sierra.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 24 Feb 88 13:32:22-PST
Date: Wed 24 Feb 88 13:34:57-PST
From: Joanne Chequer <CHEQUER@Sierra.Stanford.EDU>
Subject: SITN announcement/Andy DiPaolo
To: faculty@Score.Stanford.EDU, admin@Score.Stanford.EDU,
sec@Score.Stanford.EDU, ee-faculty@Sierra.Stanford.EDU,
ee-adminlist@Sierra.Stanford.EDU, xcomx@Sierra.Stanford.EDU
cc: chequer@Sierra.Stanford.EDU, fullerton@Sierra.Stanford.EDU,
ct.pac@Forsythe.Stanford.EDU, na.mxm@Forsythe.Stanford.EDU,
na.adp@Forsythe.Stanford.EDU, jhill@Sierra.Stanford.EDU
Message-ID: <12377364698.19.CHEQUER@Sierra.Stanford.EDU>
Dwain Fullerton has asked me to forward this announcement to you!
February 24, 1988
Dear Colleagues:
It is a pleasure to announce that Andy DiPaolo has assumed
the position of Manager of the Stanford Instructional Television
Network.
Prior to assuming this position, he was Director of Media
Services and Associate Professor at Boston University. Part of
his responsibility was to manage a network similar to SITN.
DiPaolo holds a doctoral degree in Instructional Systems
Technology from Indiana University. He has designed and
produced television products for public and private sector
organizations, and formerly taught courses in instructional
development and media design.
Bob Kincheloe, professor emeritus of electrical engineering,
has been acting director of SITN, and will continue as senior
adviser.
Please join me in welcoming Andy to the Engineering School.
His telephone number at the Network is 3-3616 and his electronic
mail address is NA.ADP@forsythe.
Dwain
!≠
-------
∂24-Feb-88 1342 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: Princeton Forum on Algorithms and Complexity
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 13:42:04 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Wed 24 Feb 88 13:35:52-PST
Received: by lindy.stanford.edu; Wed, 24 Feb 88 13:13:23 PST
Received: by Forsythe.Stanford.EDU; Wed, 24 Feb 88 13:10:32 PST
Received: by BYUADMIN (Mailer X1.25) id 6186; Wed, 24 Feb 88 14:10:31 MST
Date: Wed, 24 Feb 88 15:13:33 EST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Geoff Leach <munnari!goanna.oz.au!gl@uunet.uu.net>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: Geoff Leach <munnari!goanna.oz.au!gl@uunet.uu.net>
Subject: Re: Princeton Forum on Algorithms and Complexity
Comments: To: TheoryNet List <THEORYNT@NDSUVM1>,
"Bernard Chazelle munnari.oz" <chazelle@princeton.edu>
To: Local Distribution <aflb.tn@sushi.stanford.edu>
In-Reply-To: your article <8802120712.AA06729@jade.berkeley.edu>
Is there going to be a proceedings which can can be purchased without
going to the forum?
Geoff Leach
Department of Computer Science
RMIT
Melbourne, Australia
∂24-Feb-88 1408 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu retreat
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 14:08:27 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 24 Feb 88 14:03:57-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA02079; Wed, 24 Feb 88 14:08:00 PST
Date: Wed, 24 Feb 88 14:08:00 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8802242208.AA02079@Tenaya.stanford.edu>
To: GENESERETH@Score.stanford.edu
Cc: ac@Score.stanford.edu
In-Reply-To: Mike Genesereth's message of Wed 24 Feb 88 09:30:04-PST <12377320118.11.GENESERETH@Score.Stanford.EDU>
Subject: retreat
No, I don't have the time to organize this, but I could give a talk.
(I would ask George to organize it.) -Nils
∂24-Feb-88 1649 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu apologies
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 16:49:10 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Wed 24 Feb 88 16:41:51-PST
Received: by lindy.stanford.edu; Tue, 23 Feb 88 19:01:08 PST
Received: by Forsythe.Stanford.EDU; Tue, 23 Feb 88 18:59:13 PST
Received: by BYUADMIN (Mailer X1.25) id 5659; Tue, 23 Feb 88 19:58:49 MST
Date: Tue, 23 Feb 88 19:35:00 EDT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"CADIF::GARRY"
<garry%cadif.decnet%oak.cadif.cornell.edu@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: "CADIF::GARRY"
<garry%cadif.decnet%oak.cadif.cornell.edu@forsythe.stanford.edu>
Subject: apologies
To: Local Distribution <aflb.tn@sushi.stanford.edu>
Yesterday, in an umpteenth try to get off this list, I sent out mail to all
the addresses I could think of beginning with "THEORYNET-REQUEST" and
"THEORYNT-REQUEST". Most of them bounced. Judging by the tone and volume of
the angry mail I'm starting to receive, at least one of the messages got
posted to the whole list.
All I can think of is that some mailer out there truncated "THEORYNT-REQUEST"
to "THEORYNT" and then did the unfortunate thing.
I apologize on its behalf. Please, everybody, stop sending me mail.
garry wiegand
∂24-Feb-88 1656 @Sushi.Stanford.EDU:MAILER%CRNLVAX2.BITNET@forsythe.stanford.edu File "THEORYNT -REQMAIL" being sent to you.
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 16:56:24 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Wed 24 Feb 88 16:45:50-PST
Received: by lindy.stanford.edu; Tue, 23 Feb 88 13:39:37 PST
Received: by Forsythe.Stanford.EDU; Tue, 23 Feb 88 13:32:52 PST
Received: by BYUADMIN (Mailer X1.25) id 2103; Tue, 23 Feb 88 14:32:34 MST
Date: Tue, 23 Feb 1988 14:32:30 MST
Sender: "Revised List Processor (1.5m)" <LISTSERV%BYUADMIN.BITNET@forsythe.stanford.edu>
From: MAILER%CRNLVAX2.BITNET@forsythe.stanford.edu
To: Local Distribution <aflb.tn@sushi.stanford.edu>
Subject: File "THEORYNT -REQMAIL" being sent to you.
*--------------------------------- Cut here ----------------------------------*
Received: from batcomputer by vax2.ccs.cornell.edu (5.51/4.30)
id AA07188; Tue, 23 Feb 88 16:04:57 EST
Received: by tcgould.TN.CORNELL.EDU (5.54/1.2-Cornell-Theory-Center)
id AA01972; Tue, 23 Feb 88 16:02:44 EST
Message-Id: <8802232102.AA01972@tcgould.TN.CORNELL.EDU>
Date: 23 Feb 88 15:44:00 EDT
From: "CADIF::GARRY" <garry%cadif.decnet%oak.cadif.cornell.edu@crnlvax2.BITNET>
Subject: get me off! pls
To: "theorynt-request%ndsuvm1.bitnet" <theorynt-request@ndsuvm1.BITNET>
Please remove me from this list! The address being used for me should
look something like:
garry@geology.tn.cornell.edu
or garry%geology@cu-arpa
thanks
garry
∂24-Feb-88 1704 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Theory Net administration etc.
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 17:04:10 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Wed 24 Feb 88 16:47:34-PST
Received: by lindy.stanford.edu; Tue, 23 Feb 88 14:27:36 PST
Received: by Forsythe.Stanford.EDU; Tue, 23 Feb 88 14:25:49 PST
Received: by BYUADMIN (Mailer X1.25) id 2912; Tue, 23 Feb 88 15:24:33 MST
Date: Tue, 23 Feb 88 16:00:22 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Victor S. Miller" <VICTOR%YKTVMZ.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: "Victor S. Miller" <VICTOR%YKTVMZ.BITNET@forsythe.stanford.edu>
Subject: Theory Net administration etc.
To: Local Distribution <aflb.tn@sushi.stanford.edu>
I will repeat this again, I hope more clearly:
Theory Net will now be an unmoderated distribution list. Contributions
meant for the list (and ONLY THOSE) should be sent to THEORYNT@NDSUVM1
or THEORYNT@DEARN (both addresses on BITNET/EARN). If you have an
administrative request it can be sent to TheoryNet-request@ibm.com
or THEORYNT@YKTVMX (on bitnet/earn). Routine adminstrative requests
for addition or deletion from the list can be handled automatically
by sending mail to LISTSERV@NDSUVM1 or LISTSERV@DEARN (both on bitnet/earn),
the body of which consists of a request in the following form (this must
be adhered to -- there is no AI here!)
ADD THEORYNT Your Name
to be added to the list, or
SIGNOFF THEORYNT
to be deleted
REVIEW THEORYNT
to get the list of subscribers.
If this automatic procedure does not seem to work, please send mail to
the TheoryNet-Request address above. Do not send it to the whole list!
There are (at least) two reasons why the SIGNOFF command may not work:
1) The userid in the From: field in your mail may not be the same as
what is recorded on the list. This can happen for a variety of reasons.
2) You really aren't on the primary list. Theory Net is redistributed
at many different institutions. Look at the Received: lines cluttering
up the top of your mail. That will usually give you a clue as to where
it came from. If you can't figure it out, enclose a copy of a mail
header from a recent theorynet posting in your mail to TheoryNet-request
and I will attempt to figure it out.
I will repeat again: PLEASE DON'T SEND ADMINSTRATIVE REQUESTS TO THE WHOLE
LIST!
Victor Miller -- moderator, Theory Net
∂24-Feb-88 1748 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: get me off this list
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 17:48:31 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Wed 24 Feb 88 17:41:56-PST
Received: by lindy.stanford.edu; Tue, 23 Feb 88 13:40:38 PST
Received: by Forsythe.Stanford.EDU; Tue, 23 Feb 88 13:36:08 PST
Received: by BYUADMIN (Mailer X1.25) id 2202; Tue, 23 Feb 88 14:35:43 MST
Date: Tue, 23 Feb 88 15:48:37 EST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Robert McNaughton <mcnaught%csv.rpi.edu@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: Robert McNaughton <mcnaught%csv.rpi.edu@forsythe.stanford.edu>
Subject: Re: get me off this list
Comments: To: THEORYNT%NDSUVM1.BITNET@cunyvm.cuny.edu, sutherla@lynx.pcl.ac.uk
To: Local Distribution <aflb.tn@sushi.stanford.edu>
When you reply to Unix mail please do so in such a way that the
whole distribution list does not have to read your angry reply.
My complaint is quite justified, especially because your complaint
is meant to minimize unwanted mail. Bob McNaughton, RPI
∂24-Feb-88 1834 @Sushi.Stanford.EDU:gangolli@labrea.Stanford.EDU Talk of Interest
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 18:34:05 PST
Received: from labrea.Stanford.EDU by Sushi.Stanford.EDU with TCP; Wed 24 Feb 88 18:27:49-PST
Received: by labrea.Stanford.EDU; Tue, 23 Feb 88 12:24:06 PST
Date: Tue, 23 Feb 88 12:24:06 PST
From: Anil Gangolli <gangolli@labrea.Stanford.EDU>
Subject: Talk of Interest
To: aflb.su@sushi.Stanford.EDU
Karel de Leeuw Memorial Lecture
Freeman Dyson
A Walk Through Ramanujan's Garden
Friday, Feb. 26, 4:15pm
Cubberley Auditorium (Education Building)
∂24-Feb-88 1948 LOGMTC-mailer Godel's incompleteness theorems for Logic Lunch
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 24 Feb 88 19:16:20 PST
Received: by csli.stanford.edu (3.2/4.7); Wed, 24 Feb 88 19:19:30 PST
Date: Wed 24 Feb 88 19:19:29-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: Godel's incompleteness theorems for Logic Lunch
To: logic@csli.stanford.edu
Message-Id: <572757569.0.SF@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@CSLI.Stanford.EDU>
I'll be speaking about an approach to Godel's incompleteness theorems
that I think is more natural, and involves less hand-waving than what
one usually sees. This is based on my article in Logic Colloquium '80,
on Inductively presented systems and the formalization of metamathematics.
of which I will
-------
∂24-Feb-88 1948 LOGMTC-mailer Completion of an incomplete message.
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 24 Feb 88 19:28:17 PST
Received: by csli.stanford.edu (3.2/4.7); Wed, 24 Feb 88 19:31:29 PST
Date: Wed 24 Feb 88 19:31:28-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: Completion of an incomplete message.
To: logic@csli.stanford.edu
Message-Id: <572758288.0.SF@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@CSLI.Stanford.EDU>
I will be speaking at the next couple of logic lunches on a more natural
approach (I think) to Godel's incompleteness theorems. This is based
on a modified version of my article in Logic Colloquium '80, of which
I will make copies available. I'll start this coming Monday at noon,
in Room 383N (3d floor Math lounge).
Sol Feferman
-------
∂24-Feb-88 1948 emma@russell.stanford.edu CSLI Calendar, February 25, 3:19
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 24 Feb 88 19:13:27 PST
Received: from russell.stanford.edu by csli.stanford.edu (3.2/4.7); Wed, 24 Feb 88 17:42:05 PST
Received: by russell.stanford.edu (3.2/4.7); Wed, 24 Feb 88 17:43:27 PST
Date: Wed, 24 Feb 88 17:43:27 PST
From: emma@russell.stanford.edu (Emma Pease)
To: friends@russell.stanford.edu
Subject: CSLI Calendar, February 25, 3:19
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
25 February 1988 Stanford Vol. 3, No. 19
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 25 February 1988
12 noon TINLunch
Ventura Hall Reading: "Babe Ruth Homered his Way into the
Conference Room Hearts of America"
by Ray Jackendoff, Brandeis University
Discussion led by Annie Zaenen
(zaenen.pa@xerox.com)
Abstract below
2:15 p.m. CSLI Seminar
Room G-19 Implementing a BDI agent
Redwood Hall Robert C. Moore
(bmoore@ai.sri.com)
Abstract below
3:30 p.m. Tea
Ventura Hall
--------------
CSLI ACTIVITIES FOR NEXT THURSDAY, 3 March 1988
2:15 p.m. CSLI Seminar
Room G-19 Intelligent Communicating Agents III: Communication
Redwood Hall Phil Cohen
(pcohen@warbucks.ai.sri.com)
Abstract below
--------------
ANNOUNCEMENT
Next week there will be no TINLunch or tea because CSLI will be moving
into its new building. The seminar will be held.
--------------
THIS WEEK'S TINLUNCH
Reading: "Babe Ruth Homered his Way into the Hearts of America"
by Ray Jackendoff, Brandeis University
Discussion led by Annie Zaenen
(zaenen.pa@xerox.com)
February 25
This paper is concerned with the mapping between syntactic structure
and semantic/conceptual structure. When the one doesn't reflect the
other in a direct way, one can either complicate the syntactic
structure (e.g., by assuming a deep structure that would reflect the
conceptual structure more directly) or one can complicate the
correspondence rules. Jackendoff starts from his own specific
assumptions about the conceptual structure (elaborated in his book
"Semantics and Cognition" (MIT Press 1983) and his paper "The Status
of Thematic Roles in Linguistic Theory" (LI,1987)) and discusses one
case in which the syntax/semantics mapping is not direct; the one
exemplified in sentences like `Babe Ruth homered his way into the
hearts of America.' He concludes that a syntactic solution to the
problem is not appealing but that one has either to claim that one has
a kind of idiom or that the correspondence rules have to be
complicated. The issue addressed arises of course in all theories
trying to spell out the syntax-semantics mapping; the assumptions made
here are different in their specifics from those that most of us would
make but are stated in a notation that is rather close to an attribute
value representation and they argue for a `surfacey' syntax, at least
in this case, so I hope they are sufficiently close to inspire people
to think about their own approaches to this and similar problems.
---------------
THIS WEEK'S SEMINAR
Implementing a BDI Agent
Robert C. Moore
(bmoore@ai.sri.com)
February 25
The BDI (Belief-Desire-Intention) model of rational agency is a
familiar one around CSLI, having been the focus of the RATAG project
for about three years. As part of the ICA (Intelligent, Communicating
Agents) project, we are attempting to do a complete implementation of
an agent based on the BDI model. As always, implementation forces us
to confront issues that we had previously overlooked. This talk will
focus on a number of those issues including:
a formal semantics for desire that can be used to motivate action;
extending the notion of dependency-directed belief revision
("truth maintenance") to include the dependency of intentions on
desires and beliefs and the dependency of beliefs on intentions;
combining inference and planning by treating intentions as
"assumable" propositions that one encounters in trying to infer
that one's beliefs will be satisfied.
--------------
NEXT WEEK'S SEMINAR
Intelligent Communicating Agents III: Communication
Phil Cohen
(pcohen@warbucks.ai.sri.com)
March 3
In this talk I will describe some of the kinds of communicative acts
needed by autonomous agents. Specifically, I will sketch a formalism
in which to describe informative, directive, and commissive acts that
will be required to get cooperative behavior. The definitions of the
actions will be varied as we allow various possibilities for agents'
being insincere, uncooperative, etc. Finally, if there is time, I
will explore what it takes for agents to act jointly, and how
communication fits in.
∂24-Feb-88 1953 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu 11TH COLUMBIA UNIVERSITY THEORY DAY
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 19:51:44 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Wed 24 Feb 88 19:42:38-PST
Received: by lindy.stanford.edu; Mon, 22 Feb 88 15:07:00 PST
Received: by Forsythe.Stanford.EDU; Mon, 22 Feb 88 15:03:00 PST
Received: by BYUADMIN (Mailer X1.25) id 5009; Mon, 22 Feb 88 16:00:59 MST
Date: Mon, 22 Feb 88 16:40:12 CST
Reply-To: TheoryNet List <THEORYNT@ndsuvm1>,
Lisa Wolfe <WOLFE%CS.COLUMBIA.EDU@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT@ndsuvm1>
From: Lisa Wolfe <WOLFE%CS.COLUMBIA.EDU@forsythe.stanford.edu>
Subject: 11TH COLUMBIA UNIVERSITY THEORY DAY
Comments: To: THEORYNT%NDSUVM1.BITNET@CUNYVM.CUNY.EDU
To: Local Distribution <aflb.tn@sushi.stanford.edu>
The format of the 11th theoryday will be different. The entire
afternoon session will be devoted to celebrating Zvi's recent endowed
chair. Please note that theory day will be held in the regular place:
the fifteenth floor.
THE 11TH THEORY DAY
at Columbia University
SPONSORED BY THE DEPARTMENT OF COMPUTER SCIENCE
FRIDAY, APRIL 8, 1988
10:00 DR. ALFRED V. AHO
AT&T Bell Laboratories
"FROM THEORY TO PRACTICE"
11:00 PROFESSOR LASZLO BABAI
Eotvos University & University of Chicago
"PERMUTATION GROUP ALGORITHMS"
2:00 PROFESSOR ZVI GALIL
Columbia University & Tel-Aviv University
"EFFICIENT ALGORITHMS WITH APPLICATIONS
TO MOLECULAR BIOLOGY"
3:15 RECEPTION AT THE COMPUTER SCIENCE DEPARTMENT
Coffee will be available at 9:30 am.
All lectures will be in the Kellogg Conference Center on the fifteenth
floor of the International Affairs Building, 118th Street and
Amsterdam Avenue.
The lectures are free and open to the public.
Call (212) 280-2736 for more information.
-------
∂24-Feb-88 1950 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu FOCS call for papers
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 19:48:58 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Wed 24 Feb 88 19:41:25-PST
Received: by lindy.stanford.edu; Mon, 22 Feb 88 20:09:38 PST
Received: by Forsythe.Stanford.EDU; Mon, 22 Feb 88 20:07:28 PST
Received: by BYUADMIN (Mailer X1.25) id 0214; Mon, 22 Feb 88 20:52:37 MST
Date: Mon, 22 Feb 88 21:14:37 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Dexter Kozen <kozen%kvasir.cs.cornell.edu@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Dexter Kozen <kozen%kvasir.cs.cornell.edu@forsythe.stanford.edu>
Subject: FOCS call for papers
To: Local Distribution <aflb.tn@sushi.stanford.edu>
------------------------------------------------------
CALL FOR PAPERS
1988 IEEE Symposium on
Foundations of Computer Science
The 29th Annual IEEE Symposium on Foundations of Computer Science will be
held at the Crowne Plaza Hotel in White Plains, New York on October 24-26,
1988. The Symposium is sponsored by the IEEE Computer Society's Technical
Committee on Mathematical Foundations of Computing.
Papers presenting original research on theoretical aspects of computer
science are sought. Suggested topics include:
Algorithms and Data Structures Logic and Semantics of Programs
Computability and Complexity Theory Parallel and Distributed Computation
Cryptography Robotics and Machine Learning
Databases Automata and Formal Languages
VLSI Computation and Design
Persons wishing to submit a paper should send 15 copies of an extended
abstract by May 9, 1988 to the program committee chair:
Dexter Kozen
Department of Computer Science
4126 Upson Hall
Cornell University
Ithaca, New York 14853-7501
Submissions or revisions received after May 9, 1988 will not be considered.
Authors will be notified of acceptance or rejection by June 25, 1988. A
final copy of each accepted paper, typed on special forms for inclusion in
the Symposium proceedings, will be due by August 8, 1988.
Submission format: Abstracts should begin with a succinct statement of
the problems that are considered in the paper, the main results achieved,
an explanation of the significance of the work, and a comparison to past
research. This material should be readily understandable to nonspecialists.
Technical development, directed toward the specialist, should follow as
appropriate. The entire extended abstract must not exceed 2500 words or
10 double-spaced pages. Abstracts deviating significantly from these
guidelines will not be considered.
Meeting format: Authors of accepted papers will be expected to present
their work at the Symposium. The format of the meeting, including time
allocations for presentations and scheduling of sessions, will be
determined by the Program Committee. If warranted, the Committee will
compose a program of parallel sessions.
Machtey Award for Best Student Paper: This award of up to $400, to help
defray the expenses for attending the Symposium, will be given for that
paper which the Program Committee judges to be the most outstanding paper
written solely by a student or students. To be considered for the award,
an abstract must be accompanaied by a letter identifying all authors as
full-time students at the time of submission. At its discretion, the
Committee may decline to make the award or may split the award among two
or more papers.
Conference Chair: Program Committee Chair: Local Arrangements Chair:
Christos Papadimitriou Dexter Kozen Alok Aggarwal
EE&CS Department Computer Science Dept. IBM Thomas J. Watson
University of California, 4126 Upson Hall Research Center
San Diego Cornell University P.O. Box 218
La Jolla, CA 92037 Ithaca, NY 14853-7501 Yorktown Heights, NY 10598
Program Committee:
Michael Ben-Or Joachim von zur Gathen John Mitchell
Manuel Blum Deborah Joseph Arnold Rosenberg
Cynthia Dwork Dexter Kozen Raimund Seidel
Harold Gabow Silvio Micali Janos Simon
∂24-Feb-88 1954 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu get me off this list
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 19:46:23 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Wed 24 Feb 88 19:41:05-PST
Received: by lindy.stanford.edu; Tue, 23 Feb 88 01:09:42 PST
Received: by Forsythe.Stanford.EDU; Tue, 23 Feb 88 01:07:45 PST
Received: by BYUADMIN (Mailer X1.25) id 2813; Tue, 23 Feb 88 02:07:45 MST
Date: Tue, 23 Feb 88 02:53:52 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Ewan Sutherland <sutherla%LYNX.PCL.AC.UK@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: Ewan Sutherland <sutherla%LYNX.PCL.AC.UK@forsythe.stanford.edu>
Subject: get me off this list
To: Local Distribution <aflb.tn@sushi.stanford.edu>
How does one force this list to stop sending me mail ?
Perhaps, by threatening to reply to every item ?
For the TENTH time, kindly remove my name!!!!!!
∂24-Feb-88 1955 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu add distribution
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 19:54:49 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Wed 24 Feb 88 19:43:11-PST
Received: by lindy.stanford.edu; Mon, 22 Feb 88 14:39:18 PST
Received: by Forsythe.Stanford.EDU; Mon, 22 Feb 88 14:37:25 PST
Received: by BYUADMIN (Mailer X1.25) id 4697; Mon, 22 Feb 88 15:37:15 MST
Date: Mon, 22 Feb 88 16:52:57 est
Reply-To: TheoryNet List <THEORYNT@ndsuvm1>,
Bob Allen <rba@flash.bellcore.com>
Sender: TheoryNet List <THEORYNT@ndsuvm1>
From: Bob Allen <rba@flash.bellcore.com>
Subject: add distribution
Comments: To: theorynt%ndsuvm1.bitnet@cunyvm.cuny.edu
To: Local Distribution <aflb.tn@sushi.stanford.edu>
please add bellcore-theorynt@bellcore.com (arpanet) to the distribution list
∂24-Feb-88 2359 @Score.Stanford.EDU:coraki!pratt@Sun.COM retreat
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 23:59:13 PST
Received: from Sun.COM by SCORE.STANFORD.EDU with TCP; Wed 24 Feb 88 23:54:53-PST
Received: from sun.Sun.COM ([129.144.1.3]) by Sun.COM (4.0/SMI-4.0)
id AA00681; Wed, 24 Feb 88 23:59:25 PST
Received: from coraki.UUCP by sun.Sun.COM (4.0/SMI-4.0)
id AA27848; Wed, 24 Feb 88 23:59:59 PST
Received: by (4.0/SMI-4.0Beta)
id AA16713; Wed, 24 Feb 88 23:12:33 PST
Date: Wed, 24 Feb 88 23:12:33 PST
From: coraki!pratt@Sun.COM (Vaughan Pratt)
Message-Id: <8802250712.AA16713@>
To: ac@score.stanford.edu
Subject: retreat
MIT's Lab. for CS has (had?) a one-day show-and-tell each year at
Endicott House, their version of the Buck Estate. The one-day format
has the advantage of eating less into our crowded schedule, giving us
that much more time to actually do the work as opposed to report on it.
Since we haven't done this before, one might make the case for two days
as a sort of catch-up measure, though I'd personally prefer one day.
-v
∂25-Feb-88 0554 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu A Variant of Bin Packing
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Feb 88 05:54:02 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Thu 25 Feb 88 05:48:50-PST
Received: by lindy.stanford.edu; Thu, 25 Feb 88 05:54:19 PST
Received: by Forsythe.Stanford.EDU; Thu, 25 Feb 88 05:52:36 PST
Received: by BYUADMIN (Mailer X1.25) id 3444; Thu, 25 Feb 88 06:52:18 MST
Date: Thu, 25 Feb 88 07:33:43 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Chris Long <clong%TOPAZ.RUTGERS.EDU@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Chris Long <clong%TOPAZ.RUTGERS.EDU@forsythe.stanford.edu>
Subject: A Variant of Bin Packing
To: Local Distribution <aflb.tn@sushi.stanford.edu>
I need help (i.e. an efficient algorithm or pointers to such) on the
following problem:
We have k bins of varying sizes. Bin(i) can only hold items of type
type(i), and each type(i) is distinct. Each bin has a size associated
with it, i.e. bin(i) can hold at most size(i) items of type type(i).
Now we have a certain number of boxes we wish to pack into these bins
with each box containing a given number of items of each type. Do
algorithms exist which give good approximations to a perfectly
packed set of bins? If we were given that a perfect packing exists,
how effiecient could we be?
An example:
bin(1) can hold 3 items of type(1); bin(2) can hold 2 items of
type(2).
box(1) contains 2 type(1)'s, 1 type(2);
box(2) contains 3 type(1)'s, 0 type(2)'s;
box(3) contains 1 type(1)'s, 1 type(2).
In this case box(1) and box(3) together yield a perfect packing.
In my application, the number of bins is 20-30, and the number
of boxes is 200-300; we also know a perfect packing exists.
Comments?
--
Chris Long
Rutgers University
RPO 1878 CN 5063
New Brunswick, NJ 08903
(201)-932-1160
∂25-Feb-88 0936 @Score.Stanford.EDU:ullman@navajo.stanford.edu Ronaldo Ama
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Feb 88 09:36:32 PST
Received: from navajo.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 25 Feb 88 09:29:02-PST
Received: by navajo.stanford.edu; Thu, 25 Feb 88 09:28:59 PST
Date: Thu, 25 Feb 88 09:28:59 PST
From: Jeff Ullman <ullman@navajo.stanford.edu>
Subject: Ronaldo Ama
To: phd-adm@score.stanford.edu
I've been asked to comment on Ama's performance, especially his
English. I know him from the 345 course that he took from me last year.
He was one of the handful of people most likely to make comments
or questions, and he certainly had no trouble expressing himself
in English. He also demonstrated excellent understanding of the
material. His rank in the class was 11/40, better than some of our
present Ph. D. students, worse than others.
---jdu
∂25-Feb-88 1152 LOGMTC-mailer Logic seminar
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 25 Feb 88 11:52:03 PST
Received: from Sushi.Stanford.EDU by csli.stanford.edu (3.2/4.7); Thu, 25 Feb 88 11:55:15 PST
Date: Thu 25 Feb 88 11:47:52-PST
From: Tim Fernando <FERNANDO@Sushi.Stanford.EDU>
Subject: Logic seminar
To: logic@CSLI.Stanford.EDU
Message-Id: <12377607348.20.FERNANDO@Sushi.Stanford.EDU>
Title: A survey of some syntactic aspects of typed lambda calculi
Speaker: Tim Fernando
Time: Tuesday, March 1, 4:15-5:30
Place: 381T, Math corner
Abstract:
This talk will cover (strong) normalization and the representation
of functions in simple and polymorphic typed lambda calculi. Basic
results will be stated, and some of the ideas behind them mentioned.
Needless to say, the talk is intended as an introduction for those
new to the field.
-------
∂25-Feb-88 1357 @Score.Stanford.EDU:cheriton@Pescadero.stanford.edu Re: retreat
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Feb 88 13:57:30 PST
Received: from Pescadero by SCORE.STANFORD.EDU with TCP; Thu 25 Feb 88 13:52:45-PST
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA03718; Thu, 25 Feb 88 13:57:17 PST
Date: Thu, 25 Feb 88 13:57:17 PST
From: "David Cheriton" <cheriton@pescadero.stanford.edu>
Message-Id: <8802252157.AA03718@Pescadero>
To: ac@score.stanford.edu, coraki!pratt@sun.com
Subject: Re: retreat
I think a one-day at Buck would be a good start. Also, I suggest focusing more
on general direction of areas and such rather than specific current research.
∂25-Feb-88 1630 TAJNAI@Score.Stanford.EDU IBM Call for Fellowship Nominations
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Feb 88 16:30:00 PST
Date: Thu 25 Feb 88 15:37:12-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: IBM Call for Fellowship Nominations
To: faculty@Score.Stanford.EDU
Message-ID: <12377649098.9.TAJNAI@Score.Stanford.EDU>
Please send your nominations to me for the IBM Fellowship as quickly
as possible. the deadline for applications is 3/18, so we must move.
I recommend that you nominate students who have passed the quals,
who have published, and for whom you are willing to write an outstanding
letter of recommendation.
Carolyn
p.s. This is for CSD PHD students only. No restrictions on
citizenship.
-------
∂25-Feb-88 1656 @Score.Stanford.EDU:jcm@navajo.stanford.edu Re: retreat
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Feb 88 16:56:39 PST
Received: from navajo.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 25 Feb 88 16:14:03-PST
Received: by navajo.stanford.edu; Thu, 25 Feb 88 16:13:59 PST
Date: Thu, 25 Feb 88 16:13:59 PST
From: John Mitchell <jcm@navajo.stanford.edu>
Subject: Re: retreat
To: ac@score.stanford.edu, cheriton@pescadero.stanford.edu,
coraki!pratt@sun.com
I also support the one-day idea. Perhaps if this will be a
regular occasion, it might make sense to focus on one
group or two, rather than having everyone try to present
something. We would all get our chance eventually, and
narrowing the focus might make it easier to make sense
of what is being said.
John
∂25-Feb-88 1730 GENESERETH@Score.Stanford.EDU Re: retreat
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Feb 88 17:30:11 PST
Date: Thu 25 Feb 88 17:25:19-PST
From: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Subject: Re: retreat
To: cheriton@Pescadero.Stanford.EDU
cc: ac@Score.Stanford.EDU, coraki!pratt@SUN.COM
In-Reply-To: <8802252157.AA03718@Pescadero>
Message-ID: <12377668780.11.GENESERETH@Score.Stanford.EDU>
Two things:
(1) I just called Jack Dempsey who handles Buck, and that place would be
too small if we number more than about 25.
(2) In an earlier nmote I suggested that people try to pitch their presentations
at a high enough level that they are understandable by others. David suggests
general directions rather than specific reserch, and I agree. However, it is
also very easy to speak at too general a level with the resultthat one's
descriptions are just a bunch of fluff. It is going to take a little active
effort on our parts if we are to make something of this idea. Solid
presentations with adequate motivation and a good sense of direction. I for
one am willing to make the effort. How about the rest of you?
mrg
-------
∂25-Feb-88 1812 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu IBM Call for Fellowship Nominations
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Feb 88 18:12:08 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 25 Feb 88 18:07:13-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA03708; Thu, 25 Feb 88 18:11:28 PST
Date: Thu, 25 Feb 88 18:11:28 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8802260211.AA03708@Tenaya.stanford.edu>
To: TAJNAI@Score.stanford.edu
Cc: faculty@Score.stanford.edu
In-Reply-To: Carolyn Tajnai's message of Thu 25 Feb 88 15:37:12-PST <12377649098.9.TAJNAI@Score.Stanford.EDU>
Subject: IBM Call for Fellowship Nominations
I nominate Karen Myers.
-Nils
∂26-Feb-88 1100 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talks
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Feb 88 10:59:58 PST
Date: Fri 26 Feb 88 10:49:40-PST
From: Anil R. Gangolli <GANGOLLI@Sushi.Stanford.EDU>
Subject: Upcoming AFLB Talks
To: aflb.all@Sushi.Stanford.EDU
Office Phone: (415) 723-3605
Message-ID: <12377858899.44.GANGOLLI@Sushi.Stanford.EDU>
THIS WEEK:
3-March-1988: Algorithms for Lunch Bunch
Problem Session
Research and recreational problems will be
discussed. Participants are requested to bring
problems to present. If you have a problem
whose presentation will require a substantial
portion of the meeting, please notify me in
advance. (gangolli@sushi.stanford.edu)
NEXT WEEK:
10-March-1988: Shay Kutten (IBM T.J. Watson Research Ctr.)
NEW MODELS AND ALGORITHMS FOR FUTURE NETWORKS
In future networks transmission and switching capacity will dominate
processing capacity. In this paper we investigate the way in which
distributed algorithms should be changed in order to operate
efficiently in this new environment. We introduce a new model for
distributed algorithms which makes explicit the difference between
switching and processing. Based on this new model we define "message"
and time complexity measures which essentially consider switching and
transmission to be free of cost. The price we count is for setting a
switch. This model can be viewed as a compromise between PRAM (that
ignores communication) and the standard model of distributed computing
(that ignores computation).
In order to demonstrate the capabilities of the new model we examine
two problems that have been extensively studied in the distributed
algorithm and networking literature. For the problem of maintaining
network topology we devise a broadcast algorithm which takes O(n)
"messages" and O(log n) time. For the problem of leader election we
present a simple algorithm that uses O(n) "messages" and O(n) time.
Both algorithms are better than the existing algorithms under the new
network model. Some extensions will also be discussed.
(Joint work with I. Cidon and I. Gopal.)
-------
∂26-Feb-88 1416 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu NTT Opportunities
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Feb 88 14:15:39 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 26 Feb 88 14:08:44-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA00278; Fri, 26 Feb 88 14:13:04 PST
Date: Fri, 26 Feb 88 14:13:04 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8802262213.AA00278@Tenaya.stanford.edu>
To: faculty@score
Cc: rc.neo@forsythe, et.tch@forsythe, betsy@csli
Subject: NTT Opportunities
Stanford has maintained an ongoing relationship in various ways with
NTT, the large, recently privatized
telephone/communications/electronics company in Japan. Most recently
NTT's president, Mr. Shinto, has had discussions with Prof. Tom Heller
(of the law school and of the Stanford Overseas Campus Program)
regarding ways in which NTT and Stanford might forge an even closer
relationship---one which might also involve the new Stanford
Science/Engineering Campus in Kyoto in some as-yet-unspecified way.
It is expected that future discussions with NTT would lead to research
support and other support for Stanford.
Mr. Shinto's special concern involves methodologies for designing,
programming, maintaining, etc. "real-time software systems." Examples
of such systems are telephone switching systems, banking systems,
cash-dispensing systems and the like. He is interested in finding out
if there is anything Stanford can suggest that would improve the
teaching of these technologies and/or the automatic programming of
these systems and/or productivity aids for building these systems.
At a recent meeting of Stanford people concerned with exploring how to
react to Mr. Shinto's request, I mentioned that some of our faculty
might, at least, be interested in taking part in one or a series of
seminars/workshops/classes (format to be discussed) on "real-time
software methodologies." Quite possibly, NTT research support might
develop from such a workshop. I said that I would bring this possibility
to the attention of our faculty to see if anyone out there is interested.
People who want to find out more (at a small, short meeting to be held
sometime during the week of March 7 at Stanford) should send me
a brief e.m. note expressing interest, and they will be notified of
time and place of meeting. Specific questions about this before the
meeting might be addressed to Tom Heller, et.tch@forsythe.
-Nils
∂26-Feb-88 1556 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Looking for algorithm to color *LARGE* graphs
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Feb 88 15:56:22 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Fri 26 Feb 88 15:48:42-PST
Received: by lindy.stanford.edu; Fri, 26 Feb 88 15:52:59 PST
Received: by Forsythe.Stanford.EDU; Fri, 26 Feb 88 15:50:57 PST
Received: by BYUADMIN (Mailer X1.25) id 8008; Fri, 26 Feb 88 16:45:27 MST
Date: Fri, 26 Feb 88 16:32:27 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Karl Kluge <G.GP.CS.CMU.EDU!kck%PT.CS.CMU.EDU@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Karl Kluge <G.GP.CS.CMU.EDU!kck%PT.CS.CMU.EDU@forsythe.stanford.edu>
Subject: Looking for algorithm to color *LARGE* graphs
To: Local Distribution <aflb.tn@sushi.stanford.edu>
I'm interested in doing (non-exact) minimal coloring of large
(4000 - 10000 nodes), dense (probably 90%+) graphs. The algorithms
I've been able to find in journals, etc. have been O(|V|**2) or
O(|V| + |E|) in time. Is O(|E|) the best that can be done? If anyone
can give me pointers to faster algorithms (keeping in mind that
the number of nodes and edges are large, so space complexity is also
a concern), it would be greatly appreciated.
Thanks,
Karl Kluge (kck@g.cs.cmu.edu on ARPAnet)
∂26-Feb-88 1729 @Score.Stanford.EDU:blatt@eleebana.stanford.edu applicants from Sydney University
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Feb 88 17:28:52 PST
Received: from eleebana.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 26 Feb 88 17:21:08-PST
Received: by eleebana.stanford.edu; Fri, 26 Feb 88 17:28:18 PST
Date: 26 Feb 1988 1728-PST (Friday)
From: Miriam Blatt <blatt@eleebana.stanford.edu>
To: phd-adm@score.stanford.edu
Subject: applicants from Sydney University
In-Reply-To: Jeff Ullman <ullman@navajo.stanford.edu> /
Thu, 25 Feb 88 09:28:59 PST.
There are 3 graduates from Sydney University in the first batch of
folders. Since I know all the people who provided references, I thought
you might find it helpful to look at my (approximate) rating of which
people I am most inclined to believe.
Norman Foo Norman's references should be highly reliable.
Ross Quinlan (formerly head of CS at NSW Institute of Technology,
now chair of CS at Sydney University)
Leslie Goldschlager (formerly at Sydney Univ, now chair of the CS Dept
at Monash, both good schools)
I'd be inclined to believe both of them.
Jason Catlett Probably ok. Less experienced than the others.
Jennie Seberry Inclined to be very enthusiastic. Might be ok,
but the one most likely to exaggerate.
Also, I may as well include a transcript translation. All letter grades
are guessed based on my experience at Stanford.
CR = Credit B
D = Distinction A
HD = High Distinction A+
Each grade given is an average for all courses in that field over a
full year. Thus, a 3rd year HD (over about 9 courses) is worth more
than a 1st year HD (about 3 courses) in any given subject.
All 3 students got 1st class honours in the 4th year, which is fine,
and one of them got the University Medal. This is given out to the top
student of the 4th year class, if and only if the department decides
that the top student is worthy of it. However, I don't recall the CS
Dept withholding the medal in any of the last 8 years (other departments
certainly have, but only rarely).
If you have any further questions, please mail me.
Miriam Blatt
∂26-Feb-88 1812 @Score.Stanford.EDU:blatt@eleebana.stanford.edu Addendum: Re: applicants from Sydney University
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Feb 88 18:12:21 PST
Received: from eleebana.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 26 Feb 88 18:04:49-PST
Received: by eleebana.stanford.edu; Fri, 26 Feb 88 18:11:59 PST
Date: 26 Feb 1988 1811-PST (Friday)
From: Miriam Blatt <blatt@eleebana.stanford.edu>
To: phd-adm@score.stanford.edu
Subject: Addendum: Re: applicants from Sydney University
In-Reply-To: Miriam Blatt <blatt@eleebana.stanford.edu> /
26 Feb 1988 1728-PST (Friday).
To be more precise, a Credit is AT LEAST a B average, and could be an
A- average who didn't have quite enough A level scores to get a
Distinction.
Miriam Blatt
∂26-Feb-88 2246 @Score.Stanford.EDU:dill@amadeus.stanford.edu retreat
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Feb 88 22:46:04 PST
Received: from amadeus.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 26 Feb 88 22:41:06-PST
Received: by amadeus.stanford.edu; Fri, 26 Feb 88 22:45:45 PST
Date: Fri, 26 Feb 88 22:45:45 PST
From: David Dill <dill@amadeus.stanford.edu>
Subject: retreat
To: faculty@score.stanford.edu
I think this would be very helpful for me. People from elsewhere keep
asking me about work at Stanford and I usually don't know about it.
∂27-Feb-88 0029 @Score.Stanford.EDU:cheriton@Pescadero.stanford.edu Re: NTT Opportunities
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Feb 88 00:29:35 PST
Received: from Pescadero by SCORE.STANFORD.EDU with TCP; Sat 27 Feb 88 00:23:59-PST
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA07553; Sat, 27 Feb 88 00:28:23 PST
Date: Sat, 27 Feb 88 00:28:23 PST
From: "David Cheriton" <cheriton@pescadero.stanford.edu>
Message-Id: <8802270828.AA07553@Pescadero>
To: faculty@score.stanford.edu, nilsson@tenaya.stanford.edu
Subject: Re: NTT Opportunities
Cc: betsy@csli.stanford.edu, et.tch@forsythe.stanford.edu,
rc.neo@forsythe.stanford.edu
The software my group has developed is being used for real-time control of
pulp mills in Finland and laboratory instruments produced by Tektronix.
The major deficiency I see at Stanford to teach more in this area is having
something fun and interesting to control in real-time. At Waterloo, we had
a large (toy) electric train layout for this purpose. MIT had broom balancing.
Maybe NTT wants to supply us with some library robots and the students can
get them to square dance, etc.
∂27-Feb-88 0830 @Score.Stanford.EDU:NII@SUMEX-AIM.Stanford.EDU Re: NTT Opportunities
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Feb 88 08:30:49 PST
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sat 27 Feb 88 08:25:49-PST
Date: Sat, 27 Feb 88 08:29:20 PST
From: Penny Nii <NII@SUMEX-AIM.Stanford.EDU>
Subject: Re: NTT Opportunities
To: cheriton@pescadero.stanford.edu
cc: faculty@score.stanford.edu, nilsson@tenaya.stanford.edu,
betsy@csli.stanford.edu, et.tch@forsythe.stanford.edu,
rc.neo@forsythe.stanford.edu, NII@SUMEX-AIM.Stanford.EDU
In-Reply-To: <8802270828.AA07553@Pescadero>
Message-ID: <12378095494.12.NII@SUMEX-AIM.Stanford.EDU>
If I understood Tom Heller correctly (in a brief conversation), the
main isxsue on Dr. Shinto's mind was: advanced techniques for enhancing
the productivity of software engineers. That is, NTT is just discovering:
a. the software crisis
b. that it is significantly in the software business!
Ed
-------
∂27-Feb-88 0835 @Score.Stanford.EDU:NII@SUMEX-AIM.Stanford.EDU SORRY
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Feb 88 08:35:09 PST
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sat 27 Feb 88 08:28:00-PST
Date: Sat, 27 Feb 88 08:31:36 PST
From: Penny Nii <NII@SUMEX-AIM.Stanford.EDU>
Subject: SORRY
To: FACULTY@score.stanford.edu, ET.TCH@forsythe.stanford.edu
Message-ID: <12378095908.12.NII@SUMEX-AIM.Stanford.EDU>
THE LAST MESSAGE WAS FROM ED FEIGENBAUM, NOT PENNY NII.
-------
∂27-Feb-88 1005 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu theory news circulation
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Feb 88 10:05:39 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Sat 27 Feb 88 10:00:43-PST
Received: by lindy.stanford.edu; Sat, 27 Feb 88 10:06:18 PST
Received: by Forsythe.Stanford.EDU; Sat, 27 Feb 88 10:04:11 PST
Received: by BYUADMIN (Mailer X1.25) id 2389; Sat, 27 Feb 88 10:19:44 MST
Date: Fri, 26 Feb 88 13:48:31 GMT
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Paul Taylor <pt%doc.ic.ac.uk@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: Paul Taylor <pt%doc.ic.ac.uk@forsythe.stanford.edu>
Subject: theory news circulation
To: Local Distribution <aflb.tn@sushi.stanford.edu>
I susbcribe to Albert Meyer's "types" mailing list, and, looking back
through it, notice a reference to you. Most of what I've seen in
"types" has been syntactic, whereas my interest is in semantics
(category theory, topos theory, domain theory, models of polymorphism,
stable domain theory). Does your column cover this? If so, may
I join it? What other similar lists are there?
Paul Taylor (Dr), pt@doc.ic.ac.uk, +44 1 589 5111 x 4980
Dept of Computing, Imperial College, London SW7 2BZ, UK.
∂27-Feb-88 1458 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: NTT Opportunities
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Feb 88 14:58:54 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sat 27 Feb 88 14:52:33-PST
Date: 27 Feb 88 1151 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: NTT Opportunities
To: faculty@SCORE.Stanford.EDU, nilsson@TENAYA.STANFORD.EDU
CC: betsy@CSLI.STANFORD.EDU, et.tch@FORSYTHE.STANFORD.EDU,
rc.neo@FORSYTHE.STANFORD.EDU
This sounds like an opportunity to consider some tie-ins to the new
building, such as the robotics there. There will be gobs of real time
issues in the mobile robots, and there are other building control issues
that also include real-time considerations.
Consider the problem of robot navigation in a crowded corridor. That
alone has plenty of real-time issues.
Arthur
∂28-Feb-88 0941 LOGMTC-mailer Mathematics Colloquium of logical interest
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 28 Feb 88 09:41:34 PST
Received: by csli.stanford.edu (3.2/4.7); Sun, 28 Feb 88 09:44:46 PST
Date: Sun 28 Feb 88 09:44:44-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: Mathematics Colloquium of logical interest
To: logic@csli.stanford.edu
Message-Id: <573068684.0.SF@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@CSLI.Stanford.EDU>
Speaker: Prof. Erwin Engeler, Mathematics, ETH Zurich
Title: Combinatory differential algebra
Time: Thursday, March 3, 4:15 PM
Place: Room 380W, Math Bldg 380, Stanford
∀There will be a tea before the colloquium at 3:30 PM in the 3d floor
Math Dept lounge.
Abstract:
By embedding differential fields in combinatory algebras we augment the
field operations by programming constructs such as recursion. This makes
it possible to create field extensions by what corresponds algebraically
to programmed functions. We give examples of solving differential and
functional equations in such extensions.
-------
∂28-Feb-88 1147 X3J13-mailer ISO meeting news
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 28 Feb 88 11:47:20 PST
Date: 28 Feb 1988 14:46-EST
Sender: MATHIS@A.ISI.EDU
Subject: ISO meeting news
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]28-Feb-88 14:46:29.MATHIS>
Hot news from the ISO-IEC/JTC 1/SC 22/WG 16 Lisp meeting in Paris
February 24-25, 1988.
The working group decided "The draft standard to be provided by
the Working Group within 18 months will take as starting point
COMMON LISP (with X3J13 cleanups) with treatment of major issues
and default values to be identified (including issues in the
AFNOR list and on the agenda)." They also decided on "ISLISP" as
the working name of the standard language.
There is considerable hope in both X3J13 and this ISO working
group that the results of their work match exactly (this will
require close cooperation).
∂28-Feb-88 1342 AAAI-OFFICE@SUMEX-AIM.Stanford.EDU Council Meeting in August
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Feb 88 13:42:03 PST
Date: Sun, 28 Feb 88 13:37:10 PST
From: AAAI <AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>
Subject: Council Meeting in August
To: officers: ;
cc: aaaI-OFFICE@SUMEX-AIM.Stanford.EDU
Telephone: (415) 328-3123
Postal-Address: 445 Burgess Drive, Menlo Park, CA 94025
Message-ID: <12378413679.31.AAAI-OFFICE@SUMEX-AIM.Stanford.EDU>
I would like you to put onto your calendar a full day Executive Council
meeting to be held on Monday, August 22, 1988 at the Radison-St Paul
Hotel. It will run between 9:00 am-5:00 pm . August 22 is the day
before the technical paper sessions and the opening of the trade show.
I believe we all concurred during the last Council meeting that a full
day meeting was more preferable than 2 evening sessions.
-Claudia
-------
∂28-Feb-88 1818 barwise@russell.stanford.edu Symbolic bboard
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 28 Feb 88 18:18:33 PST
Received: from russell.stanford.edu by csli.stanford.edu (3.2/4.7); Sun, 28 Feb 88 18:20:58 PST
Received: from localhost by russell.stanford.edu (3.2/4.7); Sun, 28 Feb 88 18:22:21 PST
To: ssp-faculty@russell.stanford.edu
Cc: accounts@russell.stanford.edu
Subject: Symbolic bboard
Date: Sun, 28 Feb 88 18:22:20 PST
From: Jon Barwise <barwise@russell.stanford.edu>
Thanks to Bill Palmer and Brian Roberts (cymru), I think we now have
access to future messages posted to the symbolic bboard. To post same,
though, we should send them to csli-ssp. To read it, do
rn csli-ssp
∂28-Feb-88 1948 whp4@csli.stanford.edu Re: Symbolic bboard
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 28 Feb 88 19:48:46 PST
Received: from russell.stanford.edu by csli.stanford.edu (3.2/4.7); Sun, 28 Feb 88 19:51:25 PST
Received: from csli.stanford.edu by russell.stanford.edu (3.2/4.7); Sun, 28 Feb 88 19:52:48 PST
Received: by csli.stanford.edu (3.2/4.7); Sun, 28 Feb 88 19:51:21 PST
Date: Sun 28 Feb 88 19:51:19-PST
From: Bill Palmer <WHP4@CSLI.Stanford.EDU>
Subject: Re: Symbolic bboard
To: barwise@RUSSELL.STANFORD.EDU
Cc: ssp-faculty@RUSSELL.STANFORD.EDU, accounts@RUSSELL.STANFORD.EDU
Message-Id: <573105079.0.WHP4@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@CSLI.Stanford.EDU>
To clarify:
mail to csli-ssp
read csli.ssp (with rn)
mail sent to symbolic@<one of the lots machines> will be received here, and
vice versa.
-------
∂28-Feb-88 1957 @Score.Stanford.EDU:DEK@SAIL.Stanford.EDU re retreat
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Feb 88 19:57:42 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 28 Feb 88 19:53:19-PST
Date: 28 Feb 88 1957 PST
From: Don Knuth <DEK@SAIL.Stanford.EDU>
Subject: re retreat
To: ac@SCORE.STANFORD.EDU
I vote for a two or three day retreat at some "remote" place
in a relatively isolated part of California. I'll try to explain
why such an event seems compellingly attractive to me.
I love Computer Science, but the amount of CS I don't know is shocking.
Our field continues to grow rapidly, and there's lots of great
stuff happening, but I can't even keep up with my narrow fields
of research. If this trend continues, hardly any of us will be
able to talk to each other about any shared interests except
departmental politics. (Ugh.)
One way I could catch up is by reading on my own. I have been
self-taught in CS, since CS didn't exist when I was a student,
so I could continue to read up on things myself without bothering
anybody else. But here I am surrounded by the best authorities
in the subject, people who not only know it but like to teach it.
So I would like very much to become the student of every other
professor in the department.
Here are some of the things I would like to learn, in no particular
order:
1. What is nonmonotonic reasoning, and why is it important?
2. What do the funny diamond and box symbols mean that
Zohar M and friends use? The notation seems to have something
to do with things that happen "eventually"(?); is this
"modal logic"? What are its basic concepts and why are
they important?
3. What are RISC machines, and why are they important?
4. What really goes on inside workstations, underneath
the programs I write in procedural languages?
5. What are the best current ideas about how to create
and debug programs?
6. What goes on in the Ethernet, and what are the new
network protocols that David C thinks are necessary to
achieve greater efficiency?
7. What are these "dynamic types" that Vaughan P is so
excited about, more so than I've ever known him to be?
8. What is the NAIL! system that Jeff U is developing?
9. I've seen great work done elsewhere about "animation
of algorithms". Is anybody here pursuing similar ideas?
Are people anywhere looking at "animation of databases"?
10. What are "stiff" differential equations?
11. What are Bob Floyd's new ideas about formal languages
that use UNIX-like "pipes" with automata?
12. What is the "blackboard model" that people are so
enthusiastic about?
13. How can robots do the things Jean-Claude tells us are
currently feasible?
14. Are psychologists getting closer to an understanding of how
humans can speak to each other, given our slow mental hardware
that only allows for about two levels of "logic" before
parsing decisions must be made?
15. Are automatic verification programs and theorem-proving
programs having successes?
16. How do VLSI circuits work?
17. What is the system for control of manufacturing that Brian R
and his students were working on, and is similar work
being continued?
18. What is the great LU method of decomposition and why should
I not solve linear equations in a simple-minded way?
19. What are the relations between relational database theory
and the theory of context-free languages?
20. How can LISP be compiled into efficient code?
And so on; I'm sure I have missed many questions that will come to me
as soon as I send this message off. At the Computer Forum I was able to
hear about some of the recent work by Andy Goldberg and Yoav Shoham,
and the Forsythe lectures helped me understand Medical Information Systems
a bit. In my own environment I've had a chance to learn something about half a
dozen or so recent discoveries by Leo G, Ernst M, and Bob F regarding
computational geometry, parallel algorithms, graphics, and analysis of
algorithms, and I've had a chance to see some of the exciting work
in digital audio going on at CCRMA; I imagine others on our faculty would
be quite interested to learn about these.
As you can see, most of my "Twenty Questions" are about things that are at
least 5 or 10 years old, some much older. But I would love a chance to
learn about them from my great colleagues. (I don't even dare ask about
"what's new" in most fields. No wonder we all stopped going to the
colloquiums!) Although Computer Science continues to grow at a phenomenal
rate, there still is hope: We still share so many common paradigms of
thought that we should be able to explain these things to each other with
a high-band-width rate of communication.
Is there anything I know that might be of interest to the rest of you,
at the same level of basicness as the above (things I did five years
ago that you would be embarrassed to tell me you never had time to look at,
just as I'm embarrassed to confess to you what I am clueless about)?
I could speak about "literate programming", or about the interesting (to me)
aspects of METAFONT as a declarative language. Or I could talk about some
notational conventions that crystallized last year as I wrote the text
of Concrete Mathematics, because I think they will be important tools
for people who do mathematics at all levels. I suppose comparatively few
of you would be interested in the more technical work I've been doing
about asymptotics of random graphs (that's quite specialized), but I would
certainly be willing to explain it to anybody who cares; at a retreat
I would prefer to talk about things that a large fraction of the audience
really enjoys learning.
Am I the only one who thinks I'm hopelessly out of touch with a large
percentage of CS and who wants to get closer to things? Am I the only
one who wants to learn the subject in some setting where I can ask stupid
questions without our students knowing how far behind I am?
I've just listed about 30 subjects for possible talks at a retreat, and my
list is far from complete. If a speaker prepares about 20 minutes of
remarks about any one of those topics, we would easily be able to slow him
down by another 40 minutes' worth of questions. So that gives a lower
bound of 30 hours of presentations. Ideally I'd like to have a retreat
full of short courses, that lasts a week or more, but I suppose we have to
settle for two or three days. Therefore I was surprised at some people's
comments that one day sounds like plenty; I hope this was just a first
reaction, before realizing how much better a department ours would be if
we all knew a lot more about what the others are doing.
Does anybody else share my craving for knowing what is going on? I don't
want to see mere lists of research projects and funding levels and names
of systems; I want to learn what is inside a whole lot of black boxes.
I want to learn a small part of what my students know, so that I can teach
them better. And I suspect an exchange of ideas will also lead to new
breakthroughs in science; let's face it, we are pretty smart people.
Such a retreat will have enormous benefits, it seems to me, and I think
a setting in the mountains or at the sea or some other exhilarating
site would be far superior to a meeting within biking distance at the
Buck estate. We should have time for long breaks to go hiking and talking.
(On the other hand, I realize that some things are best done with demos;
would it impossible to transport a couple workstations to Stanford's
Alpine Cottage?)
Does anybody else share any of this vision?
∂28-Feb-88 2233 @Score.Stanford.EDU:WIEDERHOLD@SUMEX-AIM.Stanford.EDU Re: re retreat
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Feb 88 22:29:54 PST
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 28 Feb 88 22:25:10-PST
Date: Sun, 28 Feb 88 22:12:05 PST
From: Gio Wiederhold <WIEDERHOLD@SUMEX-AIM.Stanford.EDU>
Subject: Re: re retreat
To: DEK@SAIL.Stanford.EDU
cc: ac@Score.Stanford.EDU
In-Reply-To: Message from "Don Knuth <DEK@SAIL.Stanford.EDU>" of Sun, 28 Feb 88 19:57:00 PST
Message-ID: <12378507416.15.WIEDERHOLD@SUMEX-AIM.Stanford.EDU>
I second Don's desire -- I try to read and keep up, at least on high
conceptual level, but fail. I learn from collegues during exams we
give our students, and in a variety of lectures --- although the content is
often unpredictable.
But ..
Catching up on twenty+ things in one weekend seems impossible.
The colloquium used to have that function, but moving it physically away
from CSD, rarely seeing any collegues or even PhD students there, has caused
a deterioration of its contents as well. Furthermore, we assign it
(as a penalty) to the most recent faculty appointment, and that makes
it hard to have quality control. Now it is a way for MS students to gain
some breadth and a cheap unit ...
If a collegual colloquium could be revived it could provide a continuation
and alternative of the retreat concept.
A very equal trade:
12 weeks * 3 quarters * 2 hours/week versus 3 days * 24 hours
I gladly give up that much time from proposal writing ...
Gio
-------
∂29-Feb-88 0811 @Score.Stanford.EDU:jlh@vsop.stanford.edu Re: re retreat
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Feb 88 08:11:23 PST
Received: from vsop.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 29 Feb 88 08:07:00-PST
Received: by vsop.stanford.edu; Mon, 29 Feb 88 08:09:28 PST
Date: 29 Feb 1988 0809-PST (Monday)
From: John Hennessy <jlh@vsop.stanford.edu>
To: Don Knuth <DEK@sail.stanford.edu>
Cc: ac@score.stanford.edu
Subject: Re: re retreat
In-Reply-To: Don Knuth <DEK@sail.stanford.edu> / 28 Feb 88 1957 PST.
I agree with Don. I would have felt reluctant to committ 2-3 days in my
schedule, but his message convinces me it's a good idea.
What I'd really like to hear about is where people think a field is
going. Unfortunately, I usually hear about this at a conference or
working group, rather than locally.
John
∂29-Feb-88 0842 HEMENWAY@Score.Stanford.EDU
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Feb 88 08:41:57 PST
Date: Mon 29 Feb 88 08:36:01-PST
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
To: phd-adm@Score.Stanford.EDU
Message-ID: <12378620998.16.HEMENWAY@Score.Stanford.EDU>
Just a reminder to please bring in your rating sheets to me as soon as
you have completed a batch.
Also, the Round 2 meeting on March 8 will indeed be held in MJH 252.
--Sharon
-------
∂29-Feb-88 0938 TAJNAI@Score.Stanford.EDU Computer program for Shakespeare?
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Feb 88 09:38:40 PST
Date: Mon 29 Feb 88 09:33:16-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Computer program for Shakespeare?
To: faculty@Score.Stanford.EDU
Message-ID: <12378631422.18.TAJNAI@Score.Stanford.EDU>
I had an inquiry this morning regarding information about an
interactive computer program that allows one to plug in new
text and change the outcome of the plot.
Anyone know who might be doing this work?
Carolyn
-------
∂29-Feb-88 1045 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Polya Policy
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Feb 88 10:45:44 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 29 Feb 88 10:29:53-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA02352; Mon, 29 Feb 88 10:34:14 PST
Date: Mon, 29 Feb 88 10:34:14 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8802291834.AA02352@Tenaya.stanford.edu>
To: students@score, faculty@score
Subject: Polya Policy
TRIAL POLICY FOR POLYA
Raul Duran, one of the student representatives, organized a meeting on
February 25 attended by some staff, some students, some faculty and me
to discuss Polya (the new DEC 8700 computer) policy as it affects
student computing.
The meeting was quite productive---with the usual frank exchange of
views.
The net result of the meeting (as I now interpret it) was that we
decided to experiment with the following Polya Policy (which we will
call PP*) for the months of April, May, and June 1988:
1) There will be four categories of accounts on Polya, all subject to the
same charging policy. (The four categories differ only in the purposes
of the computing used in each category and in who pays for that computing.)
Category SR: Sponsored Research---paid for by various research projects or
grants. (See a research PI to inquire about setting up such an account.
The research PI will be billed for and will pay for usage.)
Category UR: Unsponsored Research---paid for, typically, by the Department
and arranged either by a student or by a faculty member doing the
unsponsored research.
Category DA: Department Administrative computing paid for by the Dept.
Category SM: Student Miscellaneous computing available for all
students to do miscellaneous computing, text editing, mail, etc. Paid
for by the Department.
2) All students (BS, MS, PhD) are eligible for SM accounts. We ask
only that such accounts not be used for heavy computing, heavy
research computing, or any computing that really fits in one of the
other categories. At the present time we will put no limits on such
computing, but we will be monitoring the total charge to the Dept. for
such accounts and will have to adjust PP* in some manner if the total
cost of SM accounts is too high or if SM computing swamps the machine.
3) Heavy research computing by PhD students should be done either on
SR accounts (arranged thru a PI) or on other machines available to a
PI. When the faculty member for whom the PhD student is working does
not have adequate computing funds, such faculty member and/or the
student should discuss setting up a UR account on Polya. The
Department will have (we hope) some funds to sponsor UR
computing---either as a way of helping a faculty member while
temporarily out of research funds or to sponsor research that the
faculty of the Department feel is important and ought to be supported.
We don't want to make a big deal of the UR/SM distinction. If the
unsponsored research is light, it can be done under an SM account.
The reason for distinguishing these kinds of accounts is that the
Department would like to be able to budget UR, DA, and SM separately
so that we can make more precise arguments when we bargain for funds from
the SOE.
For PP* to succeed and transition from an experiment into long-term
tradition, people will have to use some restraint in how SM accounts
are used, research PIs will have to adopt an
"I'm-responsible-for-the-research-computing-needs-of-my-PhD-students"
philosophy, and Polya will have to be able to sell a sufficient number
of SR accounts. It may be possible at some future time to tune PP* by
giving each use category a pie-slice (which may present technical
difficulties at present) and/or to modify the charging algorithms so
that charges can be based less on cpu and more on those parts of the
system that are more easily pie-sliced.
I would be most interested to hear from all of the user community about
their reactions to PP* and any suggested modifications. I will also
be thinking about what our policy should be if PP* doesn't work.
I think it forms the basis for something that will work well for all
of us, and I congratulate the students and the interested faculty and
staff for their productive perseverence on this topic.
-Nils
∂29-Feb-88 1053 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu New Secretary
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Feb 88 10:53:25 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 29 Feb 88 10:35:52-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA02364; Mon, 29 Feb 88 10:40:05 PST
Date: Mon, 29 Feb 88 10:40:05 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8802291840.AA02364@Tenaya.stanford.edu>
To: faculty@score, staff@score
Subject: New Secretary
I have a new secretary at long last! Joyce Chandler arrived today,
full of enthusiasm for making George Wheaton's and my administrative
lives run smoothly. She will be getting up to speed on our various
computer systems---first learning about net mail (she will be
chandler@score). Drop by her office when you get a chance to say
hello and welcome her.
-Nils
∂29-Feb-88 1159 BJORK@Score.Stanford.EDU MJH modems
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Feb 88 11:59:02 PST
Date: Mon 29 Feb 88 10:58:55-PST
From: Steven Bjork <BJORK@Score.Stanford.EDU>
Subject: MJH modems
To: csd@Score.Stanford.EDU
cc: faculty@Score.Stanford.EDU
Message-ID: <12378647012.11.BJORK@Score.Stanford.EDU>
There is a new EtherTip in MJH. The phone lines that used to
go to Score now go to this tip. It's Tip-MJHf and supports
2400, 1200 and 300 baud dialup lines. The main phone number
to use is 723-8350. All sixteen lines on this group are
ganged, so it's only necessary to dial this one number.
--Steve
-------
∂29-Feb-88 1514 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Tues Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Feb 88 15:14:54 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 29 Feb 88 15:08:08-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA02647; Mon, 29 Feb 88 15:12:29 PST
Date: Mon, 29 Feb 88 15:12:29 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8802292312.AA02647@Tenaya.stanford.edu>
To: faculty@score
Subject: Tues Lunch
Tomorrow, March 1, our faculty lunch will feature Ralph Gorin and
Stuart Reges discussing plans and options for academic
computing.
-Nils
∂29-Feb-88 1815 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU re: retreat
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Feb 88 18:15:12 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 29 Feb 88 18:10:14-PST
Date: 29 Feb 88 1814 PST
From: Robert W Floyd <RWF@SAIL.Stanford.EDU>
Subject: re: retreat
To: nilsson@TENAYA.STANFORD.EDU, ac@Score.Stanford.EDU
[In reply to message from nilsson@Tenaya.stanford.edu sent Tue, 23 Feb 88 17:36:27 PST.]
For a retreat to get everybody in sounds like too much of a marathon
for one weekend. Two suggestions:
*Have one-day retreats quarterly or semiannually.
*Envision a steady state where everyone would tell his story perhaps
every second or third year. Maybe start with more than 40% presentations,
but let's not try to do it all at once and leave nothing for next year.
I suspect that many of us are involved in continuing activities of which
the yearly increments would not be significant to those in distant subjects.
I do like the idea of finding out what my colleagues do for a living, though.
∂01-Mar-88 0327 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Equational Logic Network
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 03:27:05 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 1 Mar 88 03:21:41-PST
Received: by lindy.stanford.edu; Tue, 1 Mar 88 03:27:23 PST
Received: by Forsythe.Stanford.EDU; Tue, 1 Mar 88 03:25:33 PST
Received: by BYUADMIN (Mailer X1.25) id 5877; Tue, 01 Mar 88 02:55:05 MST
Date: Mon, 29 Feb 88 08:57:00 EST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
George McNulty <N410102%UNIVSCVM.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: George McNulty <N410102%UNIVSCVM.BITNET@forsythe.stanford.edu>
Subject: Equational Logic Network
Comments: To: Pierre Lescanne <LESCANNE@POINCARE.CRIN.FR>,
THEORYNT@NDSUVM1, THEORYNT@YKTVMX, Ralph Freese <RALPH@UHCCUX>
To: Local Distribution <aflb.tn@sushi.stanford.edu>
I have just heard that an electronic network is being
set up centered on the subject of equational rewriting
and adjacent areas. I would like to be included in this
network. My address is a BITNET address:
n410102 at univscvm
By Ordinary mail I can be reached at
George McNulty
Department of Mathematics
University of South Carolina
Columbia, South Carolina 29208
USA
My colleague Ralph Freese has informed me that he would also
like to be included in this network. Here are some
e-mail addresses for him:
ralph at uhccux.bitnet
ralph at uhccux.uhcc.hawaii.edu
ralph at kahuna.math.hawaii.edu
*******
As it turns out, I am just now organizing a similar
collection of e-mail connections for people working in
universal algebra, equational logic, and lattice theory.
Perhaps it is a reasonable thing to merge these lists??
Hoping to hear from you
George McNulty
∂01-Mar-88 0918 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: Looking for algorithm to color *LARGE* graphs
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 09:18:23 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 1 Mar 88 09:11:24-PST
Received: by lindy.stanford.edu; Tue, 1 Mar 88 09:16:59 PST
Received: by Forsythe.Stanford.EDU; Tue, 1 Mar 88 09:14:55 PST
Received: by BYUADMIN (Mailer X1.25) id 4589; Tue, 01 Mar 88 10:13:57 MST
Date: Tue, 1 Mar 88 10:04:55 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Norbert Schlenker <notecnirp!nfs%princeton.edu@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Norbert Schlenker <notecnirp!nfs%princeton.edu@forsythe.stanford.edu>
Subject: Re: Looking for algorithm to color *LARGE* graphs
To: Local Distribution <aflb.tn@sushi.stanford.edu>
In article <8802262348.AA04554@jade.berkeley.edu> TheoryNet List <THEORYNT%NDSUV
>I'm interested in doing (non-exact) minimal coloring of large
>(4000 - 10000 nodes), dense (probably 90%+) graphs. The algorithms
>I've been able to find in journals, etc. have been O(|V|**2) or
>O(|V| + |E|) in time. Is O(|E|) the best that can be done? If anyone
>can give me pointers to faster algorithms (keeping in mind that
>the number of nodes and edges are large, so space complexity is also
>a concern), it would be greatly appreciated.
>
>Thanks,
>
>Karl Kluge (kck@g.cs.cmu.edu on ARPAnet)
This problem is ill specified. What do you mean by a non-exact coloring?
Do you mean a coloring that does not necessarily color adjacent vertices
differently (not a coloring in my books)? Or do you mean a coloring that
is not necessarily minimal?
In the first case, you can color the whole graph in O(|V|) time (just make
everything one color). You can't want to do this, surely.
In the second case, it is fairly obvious that Omega(|E|) time is required -
any algorithm must look at every edge to determine whether a coloring is
legal.
Regards,
Norbert
∂01-Mar-88 1406 P.PROMETHEUS@OTHELLO.STANFORD.EDU a symbolic systems club
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 1 Mar 88 14:06:31 PST
Received: from russell.stanford.edu by csli.stanford.edu (3.2/4.7); Tue, 1 Mar 88 14:08:42 PST
Received: from OTHELLO.STANFORD.EDU by russell.stanford.edu (3.2/4.7); Tue, 1 Mar 88 14:10:05 PST
Date: Tue 1 Mar 88 14:03:49-PST
From: Reid Hoffman <P.PROMETHEUS@OTHELLO.STANFORD.EDU>
Subject: a symbolic systems club
To: ssp-faculty@RUSSELL.STANFORD.EDU
Message-Id: <12378942817.27.P.PROMETHEUS@OTHELLO.STANFORD.EDU>
Hello. My name is Reid Hoffman, and I am a junior and a
symbolic systems major. Next quarter I will be organizing a
symbolic systems club (which I will call the Symbolic System
Society, or perhaps something else with a better suggestion.)
(Prof. Barwise has suggested SS Organization or SS Association as
alternatives.)
This club will be modeled loosely after the successful Undergraduate
Philosophy Club. The club will hopefully fulfill the following
purposes:
(1) To give symbolic systems majors a chance to meet one
another.
(2) To set up a regular forum through which symbolic
systems students and off-campus consulting faculty may have
some contact and interaction.
(3) To inform symbolic systems majors of opportunities
available to them, especially in relation to graduate school
possibilities.
(4) To set up a forum to explore the "field" of symbolic
systems: i.e. discuss what purpose of the symbolic systems major is
(and perhaps what it should be), what are the major concepts of
symbolic systems, are we symbolic systems? (and can we be!), and
so forth.
(5) To expose symbolic systems students to various important
people and issues in the field. (Perhaps by reading important
seminal papers, or inviting various people to speak, for instance.)
The Society will hopefully publish an syllabus each quarter of its
weekly meetings (or possibly wing it each week!) The meetings will
be at the same time each week, and will either be during a lunch hour
or during an afternoon.
If you have any suggestions for me about this club, or would wish
to participate, please send me mail. I would be very happy to either
receive suggestions by mail or meet with you and discuss it.
Otherwise, I will just send mail when we get started which details
the events for the quarter.
thank you,
reid
-------
∂01-Mar-88 1445 X3J13-mailer X3 attendee list to date
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 14:45:14 PST
Received: by labrea.Stanford.EDU; Tue, 1 Mar 88 14:06:55 PST
Received: from sunvalleymall.lucid.com by edsel id AA06854g; Tue, 1 Mar 88 13:56:26 PST
Received: by sunvalleymall id AA00420g; Tue, 1 Mar 88 14:02:49 PST
Date: Tue, 1 Mar 88 14:02:49 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8803012202.AA00420@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: X3 attendee list to date
Please let me know if your name isn't listed below and you are
attending the March meeting. I also need to know whether you
will be having lunch 3/16 and/or 3/17.
---jan---
Registration Fees
03/01/88
Name Company Paid
Masayuki Ida Aoyama Gakuin University -
Gregor Kiczales Xerox PARC -
Bob Mathis -0- -
Daniel Bobrow Xerox PARC y
Kathy Chapman Digital Equipment y
Steve Haflich Franz, Inc. y
Kevin Layer Franz, Inc. y
Thom Linden IBM y
Jeff Rininger SRI International y
Thomas Turba UNISYS Corp y
Walter van Roggen Digital Equipment y
Paul Beiser HP -
Eric Benson Lucid, Inc. -
Jeff Dalton University of Edinburgh -
Linda DeMichiel Lucid, Inc. -
Jerry Duggan HP -
Dick Gabriel Lucid, Inc. -
David Moon Symbolics, Inc. -
Julian Padget University of Bath -
Mary Van Deusen IBM Research -
JonL White Lucid, Inc. -
∂02-Mar-88 0053 @Score.Stanford.EDU:cheriton@Pescadero.stanford.edu The Electronic Notebook and the Computer Lab
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Mar 88 00:53:48 PST
Received: from Pescadero by SCORE.STANFORD.EDU with TCP; Wed 2 Mar 88 00:42:13-PST
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA06843; Wed, 2 Mar 88 00:47:01 PST
Date: Wed, 2 Mar 88 00:47:01 PST
From: "David Cheriton" <cheriton@pescadero.stanford.edu>
Message-Id: <8803020847.AA06843@Pescadero>
To: ac@score.stanford.edu
Subject: The Electronic Notebook and the Computer Lab
Following up on the lunch discussion today, I think it would be interesting
to try to characterize the type of computer we would like students to own
in the near future, following the notion I am pushing that all students should
have a computer as an "electronic notebook/workbook/textbook" that they buy
to get their coursework done, the same as they currently purchase texts,
notebooks, pencils, etc.
Then, we can try to coordinate the programming of courses to fit this model,
and mold AIR to support this model. In addition, we should push this universyt
to support this model, saving its money for special labs where we can offer
students some really special, like for instance, how about a lab of the
following beast, or similar?
(EE380 talk)
In the past 5 years the use of computers to ``visualize''
objects and phenomena has increased. With this increase a need has
arisen for a computer that combines the computational and I/O
performance of supercomputers with the ease-of use and interactivity
found in workstations. Instead of relying on commercially available
microprocessors, sophisticated new electronic circuit design tools have
enabled system implementors to design application-specific integrated
circuits (ASICs) to build portions of systems. Using these design
tools, Stellar took the next logical step and has designed a new class
of computer designed for scientific visualization. Since this new
machine architecture combines the internal MIMD techniques of parallel
and vector computing with an internal SIMD graphics processor, we call
this new class of a computer a ``Graphics Supercomputer.''
In general, I think we'll get more mileage out of a few "super labs"
than arbitrary university provision of proletariat computing.
David C.
∂02-Mar-88 1203 Common-Lisp-mailer Request to be added to mailing list...
Received: from potomac.ads.com by SAIL.Stanford.EDU with TCP; 2 Mar 88 12:03:39 PST
Received: by potomac.ads.com (5.58/1.7)
id AA11771; Wed, 2 Mar 88 15:04:38 EST
Date: Wed, 2 Mar 88 15:04:38 EST
From: John T. Nelson <jtn%potomac@potomac.ads.com>
Message-Id: <8803022004.AA11771@potomac.ads.com>
To: ansi-common-request@potomac.ads.com, common-loops-request@potomac.ads.com,
common-windows-request@potomac.ads.com
Subject: Request to be added to mailing list...
We would like to be added to your mailing list. Sorry if I'm repeating
myself but we've had a few problems with ARPAnet. Please send the
common-windows, common-loops and ansi-common lists to their respective
addresses at our machine:
post-common-loops@potomac.ads.com
post-ansi-common@potomac.ads.com
post-common-windows@potomac.ads.com
Thanks.
John T. Nelson UUCP: sun!sundc!potomac!jtn
Advanced Decision Systems Internet: jtn@potomac.ads.com
1500 Wilson Blvd #512; Arlington, VA 22209-2401 (703) 243-1611
Strange... and beautiful music
∂02-Mar-88 1350 X3J13-mailer Re: X3 attendee list to date
Received: from venera.isi.edu by SAIL.Stanford.EDU with TCP; 2 Mar 88 13:50:06 PST
Received: from isd1.isi.edu by venera.isi.edu (5.54/5.51)
id AA07388; Wed, 2 Mar 88 13:50:51 PST
Posted-Date: Wed 2 Mar 88 13:50:45-PST
Received: by isd1.isi.edu (5.54/5.51)
id AA09581; Wed, 2 Mar 88 13:50:49 PST
Date: Wed 2 Mar 88 13:50:45-PST
From: Ron Ohlander <OHLANDER@venera.isi.edu>
Subject: Re: X3 attendee list to date
To: edsel!jlz@labrea.stanford.edu
Cc: x3j13@sail.stanford.edu
Message-Id: <573342645.0.OHLANDER@VENERA.ISI.EDU>
In-Reply-To: <8803012202.AA00420@sunvalleymall.lucid.com>
Mail-System-Version: <SUN-MM(216)+TOPSLIB(128)@VENERA.ISI.EDU>
I will be attending the March meeting and will be having lunch on both
days. My registration and fee will follow shortly
Ron Ohlander
USC/ISI
-------
∂02-Mar-88 1809 emma@russell.stanford.edu CSLI Calendar, March 3, 1988, 3:20
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 2 Mar 88 18:09:19 PST
Received: from russell.stanford.edu by csli.stanford.edu (3.2/4.7); Wed, 2 Mar 88 17:32:04 PST
Received: by russell.stanford.edu (3.2/4.7); Wed, 2 Mar 88 17:33:26 PST
Date: Wed, 2 Mar 88 17:33:26 PST
From: emma@russell.stanford.edu (Emma Pease)
To: friends@russell.stanford.edu
Subject: CSLI Calendar, March 3, 1988, 3:20
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
3 March 1988 Stanford Vol. 3, No. 20
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 3 March 1988
2:15 p.m. CSLI Seminar
Room G-19 Has been postponed
Redwood Hall
--------------
ANNOUNCEMENT
This week there is no TINLunch or tea because CSLI is moving into its
new building. There will be no TINLunches or seminars on March 10,
March 17, and March 24, partly because of the move and partly because
of final exams and spring break. On March 31, we will resume Thursday
activities. The next Calendar will be on March 24.
The seminar that was planned for this week has been postponed and
so there will be no seminar tomorrow.
--------------
∂03-Mar-88 1737 TAJNAI@Score.Stanford.EDU IBM Fellowship nominations
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Mar 88 17:37:43 PST
Date: Thu 3 Mar 88 17:32:35-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: IBM Fellowship nominations
To: faculty@Score.Stanford.EDU
Message-ID: <12379505109.13.TAJNAI@Score.Stanford.EDU>
5 students have been nominated and I have to narrow it to 2. Please help
with this decision.
Kathy Morris, nominated by Jeff Ullman
Carey Williamson, nominated by David Cheriton
Tom Henzinger, nominated by Zohar Manna
Karen Myers, nominated by Nils Nilsson
John Woodfill, nominated by Mike Genesereth
I must reach a decision tomorrow, so the students can get started
collecting materials.
Carolyn
-------
∂03-Mar-88 2138 LOGMTC-mailer Logic seminar
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 3 Mar 88 21:38:05 PST
Received: by csli.stanford.edu (3.2/4.7); Thu, 3 Mar 88 21:41:21 PST
Date: Thu 3 Mar 88 21:41:19-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: Logic seminar
To: logic@csli.stanford.edu
Message-Id: <573457279.0.SF@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@CSLI.Stanford.EDU>
Speaker: Prof. John C. Mitchell, Computer Science, Stanford
Title: Empty types in polymorphic typed lambda calculus
Time: Tuesday, March 8, 4:15 PM
Place: Room 381-T, Math. Bldg., Stanford
Abstract:
The model theory of simply typed and second-order (polymorphic) lambda
calculus changes when types are allowed to be empty. For example, the
polymorphic "Boolean" typed really has exactly two elements in a second-
order model only if the absurd type $\fa t.t$ is empty. The standard
beta-eta axioms and equational inference rules which are complete when
all types are nonempty are not complete for models with empty types.
Without a little care about variable elimination, the standard rules are
not even sound. We extend the standard system to obtain a complete proof
system for models with empty types. The completeness proof is complicated
by the fact that equational term models are not so easily obtained: in
contrast to the nonempty case, not every theory with empty types is the
theory of a single model.
Joint work with Alberrt Meyer, Eugenio Moggi and Richard Statman.
-------
∂04-Mar-88 0816 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Thanks to those who responded...
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Mar 88 08:16:25 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Fri 4 Mar 88 08:10:44-PST
Received: by lindy.stanford.edu; Fri, 4 Mar 88 08:16:37 PST
Received: by Forsythe.Stanford.EDU; Fri, 4 Mar 88 08:14:49 PST
Received: by UWAVM (Mailer X1.25) id 3872; Fri, 04 Mar 88 08:12:34 PST
Date: Fri, 4 Mar 88 09:23:56 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Karl Kluge <G.GP.CS.CMU.EDU!kck%pt.cs.cmu.edu@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Karl Kluge <G.GP.CS.CMU.EDU!kck%pt.cs.cmu.edu@forsythe.stanford.edu>
Subject: Thanks to those who responded...
To: Local Distribution <aflb.tn@sushi.stanford.edu>
As was pointed out, if nothing is known beforehand about the graph
O(|E|) is the best you can do.
Several people pointed out that I could exploit a priori knowledge
of the structure of the graphs to speed up the coloring. There was
one person (Kjell Post) whose response I wasn't able to acknowledge
by email because our mailer couldn't find the host in the return
address -- thank you for your reply, I believe I have a description
of an algorithm very similar to the one you mentioned.
Thanks again,
Karl Kluge (kck@g.cs.cmu.edu)
∂04-Mar-88 0916 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Prime Implicant
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Mar 88 09:16:32 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Fri 4 Mar 88 09:10:30-PST
Received: by lindy.stanford.edu; Fri, 4 Mar 88 09:16:16 PST
Received: by Forsythe.Stanford.EDU; Fri, 4 Mar 88 09:02:04 PST
Received: by UWAVM (Mailer X1.25) id 3982; Fri, 04 Mar 88 08:22:19 PST
Date: Fri, 4 Mar 88 09:26:29 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Alex Kean <kean%cs.ubc.ca@relay.cs.net>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Alex Kean <kean%cs.ubc.ca@relay.cs.net>
Subject: Prime Implicant
To: Local Distribution <aflb.tn@sushi.stanford.edu>
I am interested in the class of algorithms that compute prime implicant.
Beside the map method [Veitch'52] [Karnaugh'53] and the tabulation method
[Quine'52, 55] [McCluskey'56] are there any NEW results since then ?
I hope that the readers in the TheoryNet can offer some pointers in finding
any references to any new results in computing prime implicant.
Alex Kean
Department of Computer Science
University of British Columbia
Vancouver, British Columbia
Canada
∂04-Mar-88 1015 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU industrial lecturers
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Mar 88 10:15:38 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 4 Mar 88 10:09:27-PST
Date: 04 Mar 88 1013 PST
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: industrial lecturers
To: faculty@SCORE.STANFORD.EDU
Here are the industrial lectureships for next year. I don't have one for
Spring. If we could get one today, it could be included. Several
leads evaporated.
Fall 1988
Topics in Computational Geometry
Discussion of selected topics in computational geometry. Emphasis on topics of
current research interest. Subjects that will be covered include range search
problems, geometric optimization problems, and finite-precision geometry.
Familiarity with analysis of algorithms is assumed.
- Frances Yao
COMMUNICATIONS SECURITY
Winter Quarter 1989
Whitfield Diffie
Bell-Northern Research
685A East Middlefield Road
Mt. View, CA 94043
(415) 968-5792
Communications Security -- Concepts of privacy and authentication in communication
systems, vulnerability to interception and modification. Basic notions of
cryptography: general system, specific key, plain text, cipher text, cryptanalysis,
illustrated by examples of cryptosystems in historical context. Certification:
known and chosen plaintext attacks, design criteria. Study of a modern conventional
cryptosystem, the U.S. Data Encryption Standard. Key Management and public key
cryptography. Examination of the RSA system, arithmetic, factoring, and prime-
finding. Cryptographic modes of operation. Security protocols for data
communication networks. Technologies for building security equipment. Pre-
requisite: general familiarity with discrete mathematics, programming and
communication systems.
Frances Yao, a former member of the Stanford Computer Science faculty, is a
research scientist with Xerox Palo Alto Research Center where her current
field of interest is computational geometry; Whitfield Diffie is manager
of secure systems research for Bell-Northern Research, and inventor of
public key cryptography.
∂04-Mar-88 1240 GANGOLLI@Sushi.Stanford.EDU Upcoming AFLB Talks
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Mar 88 12:40:31 PST
Date: Thu 3 Mar 88 17:17:44-PST
From: Anil R. Gangolli <GANGOLLI@Sushi.Stanford.EDU>
Subject: Upcoming AFLB Talks
To: aflb.all@Sushi.Stanford.EDU
Office Phone: (415) 723-3605
Message-ID: <12379502407.16.GANGOLLI@Sushi.Stanford.EDU>
Please Note:
* I have very few speakers scheduled for next quarter.
If you have anything to talk about, please volunteer!
THIS WEEK:
10-March-1988: Shay Kutten (IBM T.J. Watson Research Ctr.)
NEW MODELS AND ALGORITHMS FOR FUTURE NETWORKS
In future networks transmission and switching capacity will dominate
processing capacity. In this paper we investigate the way in which
distributed algorithms should be changed in order to operate
efficiently in this new environment. We introduce a new model for
distributed algorithms which makes explicit the difference between
switching and processing. Based on this new model we define "message"
and time complexity measures which essentially consider switching and
transmission to be free of cost. The price we count is for setting a
switch. This model can be viewed as a compromise between PRAM (that
ignores communication) and the standard model of distributed computing
(that ignores computation).
In order to demonstrate the capabilities of the new model we examine
two problems that have been extensively studied in the distributed
algorithm and networking literature. For the problem of maintaining
network topology we devise a broadcast algorithm which takes O(n)
"messages" and O(log n) time. For the problem of leader election we
present a simple algorithm that uses O(n) "messages" and O(n) time.
Both algorithms are better than the existing algorithms under the new
network model. Some extensions will also be discussed.
(Joint work with I. Cidon and I. Gopal.)
-------
∂04-Mar-88 1440 X3J13-mailer X3J13 attendee list
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Mar 88 14:40:12 PST
Received: by labrea.Stanford.EDU; Fri, 4 Mar 88 14:01:57 PST
Received: from sunvalleymall.lucid.com by edsel id AA22425g; Fri, 4 Mar 88 14:23:43 PST
Received: by sunvalleymall id AA03806g; Fri, 4 Mar 88 14:30:22 PST
Date: Fri, 4 Mar 88 14:30:22 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8803042230.AA03806@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu, paul%hpfclp@hplabs.hp.com
Subject: X3J13 attendee list
Please let me know if you have any additions/changes.
---jan---
X3J13 Attendee Information
03/04/88
Hot
Name Institute Paid L1 L2 Dinner Tub
David Bartley TI y y y - -
Paul Beiser HP - y y y -
Eric Benson Lucid, Inc. - - - y -
Daniel Bobrow Xerox PARC y y y y y
Kathy Chapman Digital Equipment y y y - -
Christopher Dabrowski NBS - y y - -
Jeff Dalton University of - y y y -
Linda DeMichiel Lucid, Inc. - - - y -
Jerry Duggan HP - y y - -
Dick Gabriel Lucid, Inc. - y y y -
Steve Haflich Franz, Inc. y - - - -
Masayuki Ida Aoyama Gakuin - y y y -
Sonya Keene Symbolics - y y - -
Gregor Kiczales Xerox PARC - y y y y
Kevin Layer Franz, Inc. y y y - -
Thom Linden IBM y - - y -
Larry Masinter Xerox PARC - y y - -
Bob Mathis -0- - y y y -
David Moon Symbolics, Inc. - y y - -
Ron Ohlander USC/ISI - y y - -
Julian Padget University of Bath - y y - -
Crispin Perdue Sun Microsystems - - - y -
Dan Pierson Encore y y y y y
Kent Pitman Symbolics - y y y -
Jeff Rininger SRI International y y y - y
Eiji Shiota Nihon Symbolics - y y y y
Guy Steele Thinking Machines, - y y y y
Thomas Turba UNISYS Corp y y y - m
Mary Van Deusen IBM Research - - - - -
Walter van Roggen Digital Equipment y y - y -
Ellen Waldrum TI - y y - -
JonL White Lucid, Inc. - - - y -
-------------------------------
10 25 24 17 6
∂04-Mar-88 1445 VARDI%ALMVMA.BITNET@forsythe.stanford.edu MFDBS89
Received: from navajo.stanford.edu by SAIL.Stanford.EDU with TCP; 4 Mar 88 14:45:52 PST
Received: from Lindy.Stanford.EDU by navajo.stanford.edu with TCP; Fri, 4 Mar 88 14:35:32 PST
Received: by lindy.stanford.edu; Fri, 4 Mar 88 14:22:34 PST
From: VARDI%ALMVMA.BITNET@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Fri, 4 Mar 88 14:20:02 PST
Date: 4 Mar 88 14:21 PST
To: NAIL@navajo.stanford.edu
Subject: MFDBS89
Date: 4 March 1988, 14:20:44 PST
From: Moshe Vardi VARDI at ALMVMA
To: NAIL at NAVAJO.STANFORD.EDU
Subject: MFDBS89
CALL FOR PAPERS
MFDBS-89
Second Symposium on Mathematical Fundamentals
of Database Theory
June 26-30, 1989
Visegrad (Hungary)
The symposium is intended to provide a European forum on
Database Theory and its extensions to Modelling and
Knowledge Bases, with a bridge to US database community. It
is organized by the Computer and Automation Institute of the
Hungarian Academy of Sciences and will be help in Visegrad
(Hungary). Visegrad is a silent, nice village on the bank
of the Danube about 40 kms to the North of Budapest with an
interesting historical atmosphere (it used to be the royal
residence.)
Papers presenting original research in database theory are
being sought. Suggested areas include: deductive database
and knowledge-based systems; algebraic, combinatorial and
logical fundamentals of data-base theory; algorithms for
transaction processing, distributed data-bases, query
processing, concurrency control, searching strategies,
security, privacy, safety; fundamentals of object oriented
models, semantical models, complex objects, nested
relations; and design theory. Authors should send five
copies of an extended abstract or full draft paper by
December 1, 1988 to one of the Program Committee Chairs:
Janos Demetrovics
Computer and Automation Institute of HAS
Budapest, P.O.B. 63., H-1502, Hungary
Barnhard Thalheim, Visiting professor
Department of Mathematics, Kuwait University
P.O.B. 5969, Kuwait 13060
The following scientists have already agreed to be members
of the Program Committee:
Serge Abiteboul (Paris, France)
Georgio Ausiello (Rome, Italy)
Francois Bancilhon (Paris, France)
Catri Berri (Jerusalem, Israel)
Joachim Biskup (Hildesheim, FRG)
Stefano Ceri (Milano, Italy)
Gyula Katona (Budapest, Hungary)
Rumjana Kirkova (Sofia, Bulgaria)
Jan Paredaens (Antwerp, Belgium)
Valerii Pasitschnik (Kiev, USSR)
Antonin Riha (Prague, CSSR)
Joachim W. Schmidt (Frankfurt, FRG)
Anatolij A. Stognij (Kiev. USSR)
Jeffery D. Ullman (Palo Alto, USA)
Moshe Y. Vardi (San Jose, USA)
Authors will be notified of acceptance or rejection by
February 15, 1989. A copy of each accepted paper will be due
to March 20, 1989, to be included in the Proceedings
published by Springer-Verlag and available at the symposium.
The Organizing Committee of the symposium:
J. Demetrovics (Chairman)
G. Katona (Co-chairman)
B. Uhrin (Secretary)
H. Hatvany (Managing Secretary)
A. Benczur
T. Remzso
R. Kerekfy
For further information please contact:
Helga Hatvany (MFDBS-89)
Computer and Automation Institute of HAS
Budapest, P.O.B. 63., H-1502, Hungary
∂04-Mar-88 1449 LOGMTC-mailer lunch Monday
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 4 Mar 88 14:49:46 PST
Received: from russell.stanford.edu by csli.stanford.edu (3.2/4.7); Fri, 4 Mar 88 14:53:02 PST
Received: from localhost by russell.stanford.edu (3.2/4.7); Fri, 4 Mar 88 14:54:27 PST
To: logic@russell.stanford.edu
Subject: lunch Monday
Date: Fri, 04 Mar 88 14:54:26 PST
From: Jon Barwise <barwise@russell.stanford.edu>
Logic lunch Monday. Sol will talk about a new coding free approach to
metamathematics.
∂04-Mar-88 1524 barwise@russell.stanford.edu Majors Event
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 4 Mar 88 15:24:16 PST
Received: from russell.stanford.edu by csli.stanford.edu (3.2/4.7); Fri, 4 Mar 88 15:26:03 PST
Received: from localhost by russell.stanford.edu (3.2/4.7); Fri, 4 Mar 88 15:27:27 PST
To: ssp-students@russell.stanford.edu
Cc: ssp-faculty@russell.stanford.edu
Subject: Majors Event
Date: Fri, 04 Mar 88 15:27:25 PST
From: Jon Barwise <barwise@russell.stanford.edu>
Major's event is set for Wednesday, April 20, from 10 -- 2. We will be
asking for student and faculty "volunteers" to help spread the word for
an hour each.
We also need ideas for a possible theme, demos, props, and other stuff
that will help the students get a feeling for what the program is about.
Please send ideas to me, Dave Hilbert, Margie, or to the symbolic bboard.
Can you think of any symbolic food, besides alphabet soup?
Jon
∂05-Mar-88 0844 VARDI@ibm.com mfdbs89
Received: from navajo.stanford.edu by SAIL.Stanford.EDU with TCP; 5 Mar 88 08:44:42 PST
Received: from ibm.com by navajo.stanford.edu with TCP; Sat, 5 Mar 88 08:38:26 PST
Date: Fri, 04 Mar 88 15:33:22 PST
Sender: vardi@ibm.com
From: Moshe Vardi <vardi@ibm.com>
To: nail@navajo.stanford.edu
Message-Id: <880304.153322.vardi@IBM.com>
Subject: mfdbs89
CALL FOR PAPERS
MFDBS-89
Second Symposium on Mathematical Fundamentals
of Database Theory
June 26-30, 1989
Visegrad (Hungary)
The symposium is intended to provide a European forum on
Database Theory and its extensions to Modelling and
Knowledge Bases, with a bridge to US database community. It
is organized by the Computer and Automation Institute of the
Hungarian Academy of Sciences and will be help in Visegrad
(Hungary). Visegrad is a silent, nice village on the bank
of the Danube about 40 kms to the North of Budapest with an
interesting historical atmosphere (it used to be the royal
residence.)
Papers presenting original research in database theory are
being sought. Suggested areas include: deductive database
and knowledge-based systems; algebraic, combinatorial and
logical fundamentals of data-base theory; algorithms for
transaction processing, distributed data-bases, query
processing, concurrency control, searching strategies,
security, privacy, safety; fundamentals of object oriented
models, semantical models, complex objects, nested
relations; and design theory. Authors should send five
copies of an extended abstract or full draft paper by
December 1, 1988 to one of the Program Committee Chairs:
Janos Demetrovics
Computer and Automation Institute of HAS
Budapest, P.O.B. 63., H-1502, Hungary
Barnhard Thalheim, Visiting professor
Department of Mathematics, Kuwait University
P.O.B. 5969, Kuwait 13060
The following scientists have already agreed to be members
of the Program Committee:
Serge Abiteboul (Paris, France)
Georgio Ausiello (Rome, Italy)
Francois Bancilhon (Paris, France)
Catri Berri (Jerusalem, Israel)
Joachim Biskup (Hildesheim, FRG)
Stefano Ceri (Milano, Italy)
Gyula Katona (Budapest, Hungary)
Rumjana Kirkova (Sofia, Bulgaria)
Jan Paredaens (Antwerp, Belgium)
Valerii Pasitschnik (Kiev, USSR)
Antonin Riha (Prague, CSSR)
Joachim W. Schmidt (Frankfurt, FRG)
Anatolij A. Stognij (Kiev. USSR)
Jeffery D. Ullman (Palo Alto, USA)
Moshe Y. Vardi (San Jose, USA)
Authors will be notified of acceptance or rejection by
February 15, 1989. A copy of each accepted paper will be due
to March 20, 1989, to be included in the Proceedings
published by Springer-Verlag and available at the symposium.
The Organizing Committee of the symposium:
J. Demetrovics (Chairman)
G. Katona (Co-chairman)
B. Uhrin (Secretary)
H. Hatvany (Managing Secretary)
A. Benczur
T. Remzso
R. Kerekfy
For further information please contact:
Helga Hatvany (MFDBS-89)
Computer and Automation Institute of HAS
Budapest, P.O.B. 63., H-1502, Hungary
∂05-Mar-88 1543 SHOHAM@Score.Stanford.EDU re: Majors Event
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 5 Mar 88 15:42:59 PST
Received: from russell.stanford.edu by csli.stanford.edu (3.2/4.7); Sat, 5 Mar 88 15:44:46 PST
Received: from Score.Stanford.EDU by russell.stanford.edu (3.2/4.7); Sat, 5 Mar 88 15:46:11 PST
Date: Sat 5 Mar 88 15:37:01-PST
From: Yoav Shoham <SHOHAM@Score.Stanford.EDU>
Subject: re: Majors Event
To: ssp-students@Russell.Stanford.EDU, ssp-faculty@Russell.Stanford.EDU
Message-Id: <12380008361.20.SHOHAM@Score.Stanford.EDU>
How about a prop on "Is SSP what you want?", which will consist of
two rings, each made up by words describing issues covered by SSP.
The one ring could include the more abstract and broad issues, the
other the technical. We would, of course, call it the Two Ring Test.
Yoav
-------
∂06-Mar-88 1535 LOGMTC-mailer logic seminar Spring quarter
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 6 Mar 88 15:35:02 PST
Received: by csli.stanford.edu (3.2/4.7); Sun, 6 Mar 88 15:38:17 PST
Date: Sun 6 Mar 88 15:38:16-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: logic seminar Spring quarter
To: logic@csli.stanford.edu
Message-Id: <573694696.0.SF@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@CSLI.Stanford.EDU>
A couple of people could not attend this quarter because of the Tuesday
time, but could attend next quarter if we moved back to Mondays (again
4:15-5:30). Is this a problem for anyone?
Sol Feferman
-------
∂06-Mar-88 1535 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Retreat
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Mar 88 15:35:07 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Sun 6 Mar 88 15:30:36-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA07284; Sun, 6 Mar 88 15:34:55 PST
Date: Sun, 6 Mar 88 15:34:55 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8803062334.AA07284@Tenaya.stanford.edu>
To: ac@score
Cc: jwilson@score
Subject: Retreat
I've read quite a bit of faculty correspondence about having a CSD/CSL
retreat to discuss technical/scientific matters. From all of that, I
conclude that we ought to have one and that it ought to be a two-day
one. It should be far enough away from Stanford so that people won't
be tempted to swing by the office to check up on things during the
retreat, but not so far as to require lots of driving. George Wheaton
and I will look into Pajaro Dunes/Monterey Dunes/Bolinas/Napa
Valley----1 1/2 hour away sorts of places with some soul-refreshing
attributes. Suggestions about possible places are solicited.
I conclude that we ought to invite the faculty and senior research
associates but not students or other staff. Let's try to get along
without spouses/friends (to minimize their boredom and our costs and
space requirements). That will also allow us to have some evening
technical conversations without risking alienation of affection.
As Don Knuth feared, Spring Quarter dates are already filling up. He
suggested the idea of a retreat and certainly wants to attend but he
will be away the weekend of May 21/22. April 16/17, April 30/31, May
14/15, May 28/29 (Memorial Day Weekend) all work for me. The earlier
ones may present scheduling difficulties; I prefer the Saturday/Sunday
of Memorial Day weekend. (The AAAS use to have their national
meetings on that weekend.) I suspect each of these possibilities
will be bad for some people who would otherwise like to attend and
participate.
It has been suggested that we may want to book the retreat site for
Friday evening also to allow some get-acquainted conversation.
A suggested format is all day Saturday intense technical sessions (not
necessarily super-polished, super-well prepared). Don's model of
being asked by a colleague in the hall (near a blackboard!) to
describe briefly what you are up to seems a good one. We could continue
on Sunday, say, until mid-afternoon or so.
Organizing a productive retreat will take a bit of care. For now, I
would like responses just on the question of preferable date(s) and
are you over 85% sure that you would attend (given that most of the
talks will be interesting to you) and would you like to give a brief
talk on your favorite computer science topic. Please respond to
George Wheaton, wheaton@athena. I'll be working with him on
organizing this. (If you are organizationally inclined, you might
want to volunteer to help.)
[To James Wilson and to CSL/EE people: James, can you make sure
that this note gets to all the members of CSL that are in EE (in
addition to those who are in CS)? I'm concerned that ac@score
doesn't reach them. (It should be modified so that it does.)
CSL people: if this is the first you have heard of a possible
retreat, I apologize. But as you can see there has been some
discussion about having one and we want it to include all
of CSD/CSL.]
-Nils
∂06-Mar-88 1542 LOGMTC-mailer Shelah's result on the van der Waerden number
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 6 Mar 88 15:42:01 PST
Received: by csli.stanford.edu (3.2/4.7); Sun, 6 Mar 88 15:45:15 PST
Date: Sun 6 Mar 88 15:45:13-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: Shelah's result on the van der Waerden number
To: Logic@csli.stanford.edu
Message-Id: <573695113.0.SF@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@CSLI.Stanford.EDU>
In a very readable paper sent from Jerusalem, Shelah shows how to
get upper bounds in E↑5 on the san der Waerden number and the
Hales Jewett numbers, thus coming close to confirming conjectures of
Ronald Graham. He also obtains primitive recursive bounds on some other
combinatorial results. Thes are dramatic improvements over the best
bounds previously known, which were on the order of the Ackermann
non-primitive recursive function. It's straight combinatorics, no
logic involved, but the question has been of interest to logicians.
Sol Feferman
-------
∂06-Mar-88 1739 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Tuesday Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Mar 88 17:38:57 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Sun 6 Mar 88 17:33:37-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA07405; Sun, 6 Mar 88 17:37:57 PST
Date: Sun, 6 Mar 88 17:37:57 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8803070137.AA07405@Tenaya.stanford.edu>
To: faculty@score
Subject: Tuesday Lunch
At the faculty lunch on Tuesday, March 8, we will discuss some issues
having to do with TAs including: extra pay for fellowship-holding
TAs?, and credit for TA-ing at other institutions? We may also
review the formula for assigning TAs to courses. -Nils
∂06-Mar-88 2348 @Score.Stanford.EDU:cheriton@Pescadero.stanford.edu Re: Tuesday Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Mar 88 23:47:58 PST
Received: from Pescadero by SCORE.STANFORD.EDU with TCP; Sun 6 Mar 88 23:41:19-PST
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA24428; Sun, 6 Mar 88 23:45:53 PST
Date: Sun, 6 Mar 88 23:45:53 PST
From: "David Cheriton" <cheriton@pescadero.stanford.edu>
Message-Id: <8803070745.AA24428@Pescadero>
To: faculty@score.stanford.edu, nilsson@tenaya.stanford.edu
Subject: Re: Tuesday Lunch
As food for thought, Mark Linton and I recently discussed TAship requirements
with Gail Kaiser of Columbia. She indicated that they require Ph.D.
students to TA two semesters and teach a one semester course as part of
their graduation requirement. Sounds like they are serious about
producing people with some teaching experience, as seems appropriate for
Ph.D. graduates. I think our requirements looks rather weak by comparison.
(I taught a junior-level semester twice as part of my Ph.D. program).
∂07-Mar-88 0643 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu nice looking graphs
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 88 06:42:55 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Mon 7 Mar 88 06:36:35-PST
Received: by lindy.stanford.edu; Mon, 7 Mar 88 06:42:43 PST
Received: by Forsythe.Stanford.EDU; Mon, 7 Mar 88 06:40:48 PST
Received: by BYUADMIN (Mailer X1.25) id 0070; Mon, 07 Mar 88 07:40:02 MST
Date: Mon, 7 Mar 88 08:33:14 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
David Harel <HAREL%WISDOM.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: David Harel <HAREL%WISDOM.BITNET@forsythe.stanford.edu>
Subject: nice looking graphs
To: Local Distribution <aflb.tn@sushi.stanford.edu>
Does anyone know of any significant work done on defining
criteria for a graph to "look nice", and on finding efficient
algorithms for generating a nice looking graph from some nongraphical
representation of it? One aspect of this, of course, is minimizing
edge crossovers, but when combined with other reasonable criteria
(such as the desire for close-to-uniform distances between nodes) this
property seems harder to attain.
So far, we have been experimenting with a simple simulated annealing
kind of algorithm, in a manner similar to that used in designing VLSI.
David Harel (harel@wisdom.bitnet)
∂07-Mar-88 1127 @Score.Stanford.EDU:DEK@SAIL.Stanford.EDU news from the undergrad committee
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 88 11:27:24 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 7 Mar 88 11:22:50-PST
Date: 07 Mar 88 1126 PST
From: Don Knuth <DEK@SAIL.Stanford.EDU>
Subject: news from the undergrad committee
To: ac@SCORE.Stanford.EDU
The undergraduate committee has had lengthy discussions about
the interface between introductory and more advanced course
in our UG curriculum. (Everything else seems to be going
reasonably well, but the interface has been fluctuating and
we hope to find the right steady state.)
I'll spare you the detailed reasoning, but simply report what
seems to be by far our best alternative for the present.
Namely, we plan to replace the present 108AB requirement by
two requirements: (a) Students either take a 5-unit course
CS106C or two 4-unit courses CS109AB. The latter is more in-depth, and
recommended for the more ambitious students (especially those who
will be going on to graduate school in CS). The former is
more practically oriented. Both would be introductions to
CS concepts analogous to an introductory course in physics;
they touch on such things as number systems, finite-state languages,
unsolvable problems, basic nonobvious algorithms, verification,
code optimization and efficiency, introductory logic and
combinatorics. Both courses involve programming assignments that
deepen the understanding of the theoretical concepts involved
(for example, to write a Turing Machine simulator, or to do
topological sorting).
Brian Reid's new text (to be completed by fall, we all hope)
will be the basis for CS109AB next year.
[Jeff Ullman and Al Aho are also thinking about a suitable
text for an introductory course at this level.]
(b) Another new 5-unit course called 107 gives students experience
programming with a variety of languages: Prolog, Lisp,
Ada, C, Smalltalk (and UNIX, to the extent that it is a language).
This course can be taken before, after, or concurrently with
the above-mentioned introductory course 106C/109AB.
[At present, 108AB is a mixture of new languages with
new theoretical concepts; that was a nice idea but it didn't
work, because the language-learning part almost completely
swamped the other material. So we are discontinuing this
approach and separating the two functions. The number 108 is
being temporarily retired.]
Another new course is CS160, Discrete Math. Apparently every
other respectable CS department, but ours, already has such a course;
many fine textbooks are on the market. Students coming from
high schools today are often totally unprepared about how to
prove anything rigorously; this course (3 units) gives them
the necessary background. CS160 replaces our remedial proofs course
CS151 (2 units), taught successfully by Stuart Reges from his own
notes; even if Stuart were here to teach it next year, and he
won't be (more's the pity), he would have recommended replacing
CS151 by CS160. Incidentally, CS160 will be a prerequisite
for CS154, CS157, and CS161. We can restore CS161 to its
previous function of teaching fundamental algorithms.
∂07-Mar-88 1156 CHANDLER@Score.Stanford.EDU faculty luncheon
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 88 11:56:44 PST
Date: Mon 7 Mar 88 11:50:42-PST
From: Joyce R. Chandler <CHANDLER@Score.Stanford.EDU>
Subject: faculty luncheon
To: faculty@Score.Stanford.EDU
cc: chandler@Score.Stanford.EDU
Message-ID: <12380491448.16.CHANDLER@Score.Stanford.EDU>
There is a faculty luncheon scheduled for tomorrow (3/8) at 12:00 in
MJH-146. The topic will be a discussion of TA issues.
-------
∂07-Mar-88 1356 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Logic and Databases
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 88 13:56:35 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 7 Mar 88 13:50:10-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA08186; Mon, 7 Mar 88 13:53:59 PST
Date: Mon, 7 Mar 88 13:53:59 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8803072153.AA08186@Tenaya.stanford.edu>
To: ac@score
Subject: Logic and Databases
The CSD faculty have previously decided that we would authorize
a PhD qualifying exam in an area that had the support and participation
of three of our faculty members. One such area is in Database Management
Systems and Knowledge-Based Management Systems (Jeff Ullman's "Area X").
Jeff Ullman, Gio Wiederhold, Michael Genesereth, and I are supporting
a proposal to give a qual in this area. Jeff has worked hard on getting
a reading list/syllabus for the proposed qual that we all agree on.
I attach it to this message (sorry for the source-file format; I hope
people can read thru it to the content or will TeX it and print it out).
I propose that the Department officially approve a qual in this area based
on Jeff's reading list. I'll assume the faculty approves of this decision
if I hear no outpouring of negative comments. (Suggestions for minor
changes to the list or any other comments about the qual can be directed
to Jeff.)
-Nils
------
\input doc/macs
\magnification1200
\tolerance500
\font\fourteen=cmr10 scaled 1440
\newcount\itemct
\itemct=0
\def\ref{\advance\itemct by1\ip{\the\itemct.}}
\def\bul{\dip{$\bullet$}}
\ctrline{{\fourteen Syllabus for Ph.\ D.\ Qualifying Examination}}
\vskip5pt
\ctrline{{\fourteen in Data- and Knowledge-Base Systems}}
\vskip10pt
\section{I.\ GENERAL MATERIAL ON DBMS/KBMS}
\ref
Wiederhold, {\sl File Organization for Database Design}, McGraw-Hill, 1987,
Ch.\ 5-8 (file organization and performance).
\ref
Wiederhold, {\sl Database Design}, McGraw-Hill, 1983, Ch.\ 7-9 (database models),
11-14 (database security and operation).
\ref
Ullman, {\sl Principles of Database Systems}, CSP, 1982,
Ch.\ 3 (network systems), Ch.\ 4 (hierarchical systems), Ch.\ 5-7 (relational
database systems and theory), 8 (query optimization), 9.3 (acyclic hypergraphs).
Ch.\ 3-7 will be replaced by Ch.\ 1,2,4,5,7 of {\sl Principles of Database and
Knowledge-Base Systems}, Vol.\ I, when available.
\ref
Ullman, Draft of Ch.\ 3 of {\sl Principles of Database and Knowledge-Base Systems}
(logic as a database model).
This item will be available from Ullman until the book is published.
\ref
Brodie and Mylopoulos, {\sl On Knowledge-Base Management Systems},
Springer-Verlag, 1986, articles 1-5, 7, 9, 10, 13-16, 18, 19, 22, 23, 38-40.
\ref
Hull and King, ``Semantic database modeling: survey, applications, and
research issues,'' USC report CRI--87--20, to appear in {\sl Computing
Surveys}.
Until available, copies may be obtained from Ullman.
\section{II.\ CONCURRENT AND DISTRIBUTED SYSTEMS}
\ref
Bernstein, Hadzilacos, and Goodman, {\sl Concurrency Control and
Recovery in Database Systems}, Addison-Wesley, 1987 Ch.\ 1, 2, 3.1--3.12,
4.1, 4.2, 5.1, 5.3, 5.4., 6, 7.
\ref
Papadimitriou, {\sl The Theory of Database Concurrency Control},
CSP, 1986, Ch.\ 1-4 (except 3.3).
\ref
Gray,
``Notes on database operating systems,''
in {\sl Operating Systems: an Advanced Course}
(R.\ Bayer, R.\ M.\ Graham, and G.\ Seegmuller, eds.),
Springer-Verlag, 1978.
\section{III.\ GENERAL ARTIFICIAL INTELLIGENCE}
\ref
Genesereth and Nilsson, {\sl Logical Foundations of AI}, Morgan-Kaufman,
Los Altos, 1987, Ch.\ 2-6, 9, 10.
\section{IV.\ DEDUCTIVE DATABASE SYSTEMS}
\ref
Minker and Gallaire, {\sl Logic and Databases}, Plenum, 1978.
Read the following articles:
\enum
\bul Reiter, ``On closed world databases'' (pp.\ 55-76),
\bul Reiter, ``Deductive question answering on relational databases'' (pp.\ 149-178),
\bul Clark, ``Negation as failure'' (pp.\ 293--324).
(Also in Ginsberg book cited below.)
\mune
\ref
Bancilhon and Ramakrishnan, ``An amateur's introduction to recursive
query processing strategies,'' {\sl 1986 SIGMOD Conf.}, pp.\ 16-52.
\ref
{\sl Proc.\ Fifth ACM Symp.\ on Principles of Database Systems}, 1986.
Read the following articles:
\enum
\bul Bancilhon, Maier, Sagiv, Ullman (pp.\ 1-15),
\bul Naughton (267-279).
\mune
\ref
{\sl Proc.\ Sixth ACM Symp.\ on Principles of Database Systems}, 1987.
Read the following articles:
\enum
\bul Kuper (11-20),
\bul Beeri et al.\ (21-37),
\bul Beeri et al.\ (214-226),
\bul Naughton and Sagiv (227-236),
\bul Beeri and Ramakrishnan (269-283),
\bul Van Gelder and Topor (313-327),
\bul Ramakrishnan, Bancilhon, and Silberschatz (328--339),
\bul Naughton (340-348),
\bul Sagiv (349-362).
\mune
\ref
Warren, ``Efficient processing of interactive relational database
queries expressed in Prolog,'' {\sl 1981 VLDB Proc.}
\ref
Reiter, ``Towards a logical reconstruction of relational database
theory,'' in {\sl On Conceptual Modeling} (Brodie, Mylopoulos, Schmidt, eds.),
Springer-Verlag, 1984.
\ref
Reiter, ``Equality and domain closure in first-order databases,''
\JACM27,2 (1980),{235--249}
\section{V.\ NONMONOTONIC REASONING}
\ref
Ginsberg, {\sl Nonmonotonic Reasoning}, Morgan-Kaufman, 1988.
Read the following articles:
\enum
\bul Ginsberg, ``Introduction to nonmonotonic reasoning,''
\bul Reiter, ``A logic for default reasoning,'' [also {\sl Artificial Intelligence} {\bf13}:2 (1980)];
\bul Reiter and Ethrington, ``On inheritance hierarchies with exceptions'';
\bul Moore, ``Semantical considerations on nonmonotonic logic,'';
\bul [also {\sl Artificial Intelligence} {\bf25}:1 (1985)];
\bul McCarthy, ``Circumscription---a form of nonmonotonic reasoning,''
[also {\sl Artificial Intelligence} {\bf13}:2 (1980)];
\bul McCarthy, ``Applications of circumscription to formalizing common-sense
knowledge'';
\bul Lifschitz, ``Closed-world databases and circumscription,'' [also {\sl Artificial Intelligence} {\bf27}:2 (1985)];
\bul Lifschitz, ``Computing circumscription'';
\bul Lifschitz, ``Pointwise circumscription'';
\bul Lifschitz, ``On the declarative semantics of logic programs with negation'';
\bul Doyle, ``A truth maintenance system'';
\bul DeKleer, ``An assumption-based truth-maintenance system'';
\bul Minker, ``On indefinite databases and the closed-world assumption''.
\mune
\ref
Van Gelder, ``Negation as failure using tight derivations for
general logic programs,'' {\sl 1986 Symp.\ Logic Prog.}, pp.\ 127-139.
\section{VI.\ REASONING ABOUT KNOWLEDGE}
\ref
Halpern and Moses, ``Knowledge and common knowledge in a distributed
environment,''
{\sl Proc.\ Fourth ACM Symp.\ on Principles of Distributed Computing}, 1984.
\ref
Chandy and Misra, ``How processes learn,''
{\sl Distributed Computing} {\bf1}:1 (1986), pp.\ 40-52.
\ref
Hadzilacos, ``A knowledge-theoretic analysis of atomic commitment
protocols,'' {\sl Sixth PODS} (1987), pp.\ 129-134.
\section{VII.\ KNOWLEDGE REPRESENTATION}
\ref
Levesque, ``Making believers out of computers,''
{\sl Artificial Intelligence} {\bf30}:1 (1986), pp.\ 81-108.
\ref
Levesque, ``Knowledge representation and reasoning,''
{\sl Annual Review of Computer Science} {\bf1} (1986), pp.\ 255-288.
\bye
∂07-Mar-88 1410 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: nice looking graphs
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 88 14:10:43 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Mon 7 Mar 88 14:03:40-PST
Received: by lindy.stanford.edu; Mon, 7 Mar 88 14:09:38 PST
Received: by Forsythe.Stanford.EDU; Mon, 7 Mar 88 11:36:47 PST
Received: by BYUADMIN (Mailer X1.25) id 6656; Mon, 07 Mar 88 12:33:46 MST
Date: Mon, 7 Mar 88 13:25:06 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
dsj@research.att.com
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: dsj@research.att.com
Subject: Re: nice looking graphs
To: Local Distribution <aflb.tn@sushi.stanford.edu>
That's a problem that everybody seems to be asking these days.
There are various attempts at automatic layout of graphs, but
nobody seems to be claiming great results.
What criteria do you use for measuring "goodness" when you're
doing simulated annealing?
(I also note that minimizing the number of crossings is NP-complete
even when you DON'T ask that the vertices be placed nicely.)
David
∂07-Mar-88 1542 X3J13-mailer new and improved list
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 88 15:42:41 PST
Received: by labrea.Stanford.EDU; Mon, 7 Mar 88 15:43:20 PST
Received: from sunvalleymall.lucid.com by edsel id AA04874g; Mon, 7 Mar 88 14:59:33 PST
Received: by sunvalleymall id AA09200g; Mon, 7 Mar 88 15:06:23 PST
Date: Mon, 7 Mar 88 15:06:23 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8803072306.AA09200@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: new and improved list
X3J13 Attendee Information
03/05/88
Lunches Sushi Hot
Name Institute Paid 3/16 3/17 Dinner Tub
David Bartley TI y y y - -
Paul Beiser HP - y y y -
Eric Benson Lucid, Inc. - - - y -
Daniel Bobrow Xerox PARC y y y y y
Skona Brittian MSC y y y y y
Kathy Chapman Digital Equipment y y y - -
Pavel Curtis Xerox PARC - y y - -
Christopher National Bureau of - y y - -
Jeff Dalton University of - y y y -
Linda DeMichiel Lucid, Inc. - y y y -
Jerry Duggan HP - y y - -
Patrick Dussud TI - y y - -
Dick Gabriel Lucid, Inc. - y y y -
Richard Greenblatt Gigamos - y y - -
Steve Haflich Franz, Inc. y - - - -
Masayuki Ida Aoyama Gakuin - y y y -
Sonya Keene Symbolics - y y - -
Gregor Kiczales Xerox PARC - y y y y
Kevin Layer Franz, Inc. y y y - -
Thom Linden IBM y - - - -
Barry Margolin Thinking Machines - y y - -
Larry Masinter Xerox PARC - y y - -
Bob Mathis -0- - y y y -
David Moon Symbolics, Inc. - y y - -
Jim O'Dell Gigamos - y y - -
Ron Ohlander USC/ISI y y y y y
Julian Padget University of Bath - y y - -
Crispin Perdue Sun Microsystems - - - y -
Dan Pierson Encore y y y y y
Kent Pitman Symbolics - y y y -
Jeff Rininger SRI International y y y - y
Eiji Shiota Nihon Symbolics - y y y y
David Slater Computer Sciences - y y - -
Guy Steele Thinking Machines, y y y y y
Thomas Turba UNISYS Corp y y y - m
Mary Van Deusen IBM Research - - - - -
Walter van Roggen Digital Equipment y y - y -
Ellen Waldrum TI - y y - -
JonL White Lucid, Inc. - - - y -
∂07-Mar-88 1732 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Roy Jones
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 88 17:32:34 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 7 Mar 88 17:21:28-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA08319; Mon, 7 Mar 88 17:25:45 PST
Date: Mon, 7 Mar 88 17:25:45 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8803080125.AA08319@Tenaya.stanford.edu>
To: csd-list@score
Cc: gibbons@sierra, eustis@sierra
Subject: Roy Jones
I have asked Roy Jones to be the Acting Assistant CSD Chairman for
Education while we formally search for a replacement for Stuart Reges.
I'm happy to say that Roy has agreed to take on this responsibility.
He will officially assume these new duties on Stuart's April 1
departure but will undoubtedly be transitioning immediately into the
job unofficially during the next few weeks. I regard this position as
extremely important for the Department and for the University and will
support Roy in every way possible as we all work to make the
educational component of our CS Department the best in the world.
-Nils
∂08-Mar-88 0644 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: nice looking graphs
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Mar 88 06:44:08 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 8 Mar 88 06:36:30-PST
Received: by lindy.stanford.edu; Tue, 8 Mar 88 06:42:45 PST
Received: by Forsythe.Stanford.EDU; Tue, 8 Mar 88 06:40:32 PST
Received: by BYUADMIN (Mailer X1.25) id 3044; Tue, 08 Mar 88 07:40:02 MST
Date: Tue, 8 Mar 88 08:18:45 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Varol Akman <mcvax!cwi.nl!varol@uunet.uu.net>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Varol Akman <mcvax!cwi.nl!varol@uunet.uu.net>
Subject: Re: nice looking graphs
To: Local Distribution <aflb.tn@sushi.stanford.edu>
This is in reply to Dr. Harel's query on nice-looking graphs:
I remember seeing an article in ACTA INFORMATICA (at most 5
years ago but probably more recently) on this subject.
Unfortunately I can't remember the author(s).
I think it was David Dobkin who published (w/ other authors)
an article on drawing graphs so that symmetry "shows up."
Theo Pavlidis published an article (coauthored w/ someone)
on beautifying pictures. This was in one of recent (last
five or so) Siggraph volumes. I don't know if this is really
relevant.
Probably all these things are known to David but hope this helps.
Regards, -Varol Akman
∂08-Mar-88 0721 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: nice looking graphs
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Mar 88 07:21:52 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 8 Mar 88 06:36:30-PST
Received: by lindy.stanford.edu; Tue, 8 Mar 88 06:42:45 PST
Received: by Forsythe.Stanford.EDU; Tue, 8 Mar 88 06:40:32 PST
Received: by BYUADMIN (Mailer X1.25) id 3044; Tue, 08 Mar 88 07:40:02 MST
Date: Tue, 8 Mar 88 08:18:45 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Varol Akman <mcvax!cwi.nl!varol@uunet.uu.net>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Varol Akman <mcvax!cwi.nl!varol@uunet.uu.net>
Subject: Re: nice looking graphs
To: Local Distribution <aflb.tn@sushi.stanford.edu>
This is in reply to Dr. Harel's query on nice-looking graphs:
I remember seeing an article in ACTA INFORMATICA (at most 5
years ago but probably more recently) on this subject.
Unfortunately I can't remember the author(s).
I think it was David Dobkin who published (w/ other authors)
an article on drawing graphs so that symmetry "shows up."
Theo Pavlidis published an article (coauthored w/ someone)
on beautifying pictures. This was in one of recent (last
five or so) Siggraph volumes. I don't know if this is really
relevant.
Probably all these things are known to David but hope this helps.
Regards, -Varol Akman
∂08-Mar-88 0810 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu COMPUTATIONAL GEOMETRY SYMPOSIUM
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Mar 88 08:10:39 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Tue 8 Mar 88 08:03:33-PST
Received: by lindy.stanford.edu; Tue, 8 Mar 88 08:00:36 PST
Received: by Forsythe.Stanford.EDU; Tue, 8 Mar 88 07:58:17 PST
Received: by BYUADMIN (Mailer X1.25) id 3717; Tue, 08 Mar 88 08:53:49 MST
Date: Tue, 8 Mar 88 08:31:19 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Herbert Edelsbrunner <edels%p.cs.uiuc.edu@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Herbert Edelsbrunner <edels%p.cs.uiuc.edu@forsythe.stanford.edu>
Subject: COMPUTATIONAL GEOMETRY SYMPOSIUM
To: Local Distribution <aflb.tn@sushi.stanford.edu>
------------------------------------------------------------------------
Fourth ACM Symposium
on
COMPUTATIONAL GEOMETRY
Urbana, Illinois, June 6-8, 1988
INFORMATION
CONFERENCE LOCATION
The conference will be held at the University of Illinois at
Urbana-Champaign. All conference sessions will be held in the
Playhouse Theater at the Krannert Center for the Performing Arts,
500 South Goodwin Avenue, Urbana, Illinois.
REGISTRATION
Advanced registration is requested using the form provided.
Registration rates go up after May 15th. A registration desk will
be open Sunday night from 7:30pm to 9:00pm, and throughout the
conference. Registrants receive one copy of the proceedings, three
breakfasts, and one dinner. Additional copies of the proceedings
will be available for sale at the registration desk.
TRANSPORTATION TO CONFERENCE
Champaign-Urbana is served by TWA and Piedmont Airlines, national
carriers, and Britt Airways, Midway Airways and Comair, The Delta
Connection, commuter carriers, and US air. Limosine service is
available from the airport to the University of Illinois campus
(7 miles) for incoming flights. AMTRAK service is available from
Chicago and points south. Champaign-Urbana is located 135 miles
south of Chicago on Interstate Routes 72, 74, and 57.
LODGING
The primary hotel for the conference is the Illinois Street Residence
Hall. It is located on campus. A block of rooms has been reserved
for conference participants until April 30, 1988. Other lodging is
also available to meet the individual needs of registrants. The
following is a listing of available lodging alternatives. Conference
attendees are urges to make their own reservations as early as
possible, as each hotel has only limited space. Room rates vary
accordingly.
The following hotels also have rooms available for the conferences:
Illini Union University Inn
1401 West Green Street 302 East John Street
Urbana, IL 61801 Champaign, IL 61820
(217) 333-3030 (217) 384-2100
toll free (800) 252-1368 in Illinois
and (800) 322-8282 outside Illinois
FURTHER INFORMATION
For additional information, please call Donna Herriott at the Office
of Conferences and Institutes, (217) 333-2883 or Herbert Edelsbrunner,
conference chair, (217) 333-6903.
------------------------------------------------------------------------
TECHNICAL PROGRAM
MONDAY morning, 9:30-12:50, June 6, 1988
Chaired by Bernard Chazelle (Princeton Unvi.)
Application of random sampling in computational geometry, II.
K. L. Clarkson (AT&T Bell Labs)
Algorithms for diametral pairs and convex hulls that are optimal,
randomized, and incremental. K. L. Clarkson and P. W. Shor (AT&T
Bell Labs)
A fast Las Vegas algorithm for triangulating a simple polygon.
K. L. Clarkson (AT&T Bell Labs), R. E. Tarjan (Princeton Univ. and
AT&T Bell Labs), and C. J. Van Wyk (AT&T Bell Labs)
Partition trees for triangle counting and other range searching
problems. E. Welzl (Freie Univ. Berlin)
Coffee Break: 10:50 am - 11:30 am
Quasi-valid range querying and its implications to nearest neighbor
problems. D. E. Willard and Y. C. Wee (State Univ. New York at Albany)
The complexity of many faces in arrangements of lines and of segments.
H. Edelsbrunner (Univ. of Illinois at Urbana-Champaign), L. J. Guibas
(DEC/SRC and Stanford Univ.), and M. Sharir (NYU and Tel Aviv Univ.)
Implicitly representing arrangements of lines or segments.
H. Edelsbrunner (Univ. of Illinois at Urbana-Champaign), L. J. Guibas
(DEC/SRC and Stanford Univ.), J. Hershberger (DEC/SRC), R. Seidel
(Univ. of California at Berkeley), M. Sharir (NYU and Tel Aviv Univ.),
J. Snoeyink (Stanford Univ.), and E. Welzl (Freie Univ. Berlin)
Red-blue intersection detection algorithms, with applications to motion
planning and collision detection. P. Agarwal (NYU) and M. Sharir
(NYU and Tel Aviv Univ.)
Lunch: 12:50 pm - 2:30 pm
MONDAY afternoon, 2:30 - 5:40, June 6, 1988
Chaired by Chanderjit Bajaj (Purdue University)
Invited address: Bruno Buchberger (Johannes Kepler Univ. Linz)
The design of LINETOOL, a geometric editor. L. W. Ericson and
C. K. Yap (NYU)
Recipes for geometry and numerical analysis - part I: an empirical
study. D. P. Dobkin and D. Silver (Princeton Univ.)
Coffee Break: 4:10 pm - 4:40 pm
Towards implementing robust geometric computations. C. M. Hoffmann
(Purdue Univ.), J. E. Hopcroft (Cornell Univ.), M. S. Karalick
(Cornell Univ. and McGill Univ.)
Simulation of simplicity: a technique to cope with degenerate cases
in geometric algorithms. H. Edelsbrunner and E. P. Muecke (Univ.
of Illinois at Urbana-Champaign)
A geometric consistency theorem for a symbolic perturbation scheme.
C. K. Yap (NYU)
Reception and banquet
TUESDAY morning, 9:30-12:50, June 7, 1988
Chaired by Christopher J. Van Wyk (AT&T Bell Labs)
Globally-equiangular triangulations of co-circular points in O(nlogn)
time. D. Mount (Univ. of Maryland) and A. Saalfeld (Bureau of the
Census)
Analysis of a simple yet efficient convex hull algorithm. M. Golin
and R. Sedgewick (Princeton Univ.)
New methods for computing visibility graphs. M. H. Overmars (Univ.
of Utrecht) and E. Welzl (Freie Univ. Berlin)
Efficient algorithms for Euclidean shortest path and visibility
problems with polygonal obstacles. S. Kapoor and S. N. Maheshwari
(Indian Inst. of Technology Dehli)
Coffee Break: 10:50 am - 11:30 am
Hidden surface removal for rectangles. M. Bern (XEROX Palo Alto
Research Center)
An efficient output-sensitive hidden-surface removal algorithm and
its parallelization. J. H. Reif and S. Sen (Duke Univ.)
Optimal parallel algorithms for polygon and point-set problems.
R. Cole (NYU), M. T. Goodrich (The Johns Hopkins Univ.)
Covering orthogonal polygons with star polygons: the perfect graph
approach. R. Motwani, A. Raghunathan, and H. Saran (Univ. of
California at Berkeley)
Lunch: 12:50 pm - 2:30 pm
TUESDAY afternoon, 2:30-5:50, June 7, 1988
Chaired by Raimund Seidel (Univ. of California at Berkeley)
Invited address: Thomas Banchoff (Brown Univ.)
Searching for empty convex polygons. D. P. Dobkin (Princeton Univ.)
H. Edelsbrunner (Univ. of Illinois at Urbana-Champaign), and
M. H. Overmars (Univ. Utrecht)
The furthest-site geodesic Voronoi diagram. B. Aronov (NYU),
S. Fortune and G. Wilfong (AT&T Bell Labs)
Coffee Break: 4:10 pm - 4:40 pm
Computing Euclidean maximum spanning trees. C. Monma (Bell
Communications Research), M. Paterson (Univ. of Warwick), S. Suri
(Bell Communications Research), and F. F. Yao (XEROX Palo Alto
Research Center)
Clustering algorithms based on minimum and maximum spanning trees.
T. Asano (Osaka Electro-Communication Univ.), B. Bhattacharya
(Simon Fraser Univ.), M. Keil (Univ. of Saskatchewan), and
F. F. Yao (XEROX Palo Alto Research Center)
On arrangements of Jordan arcs with three intersections per pair.
H. Edelsbrunner (Univ. of Illinois at Urbana-Champaign), L. J. Guibas
(DEC/SRC and Stanford Univ.), J. Hershberger (DEC/SRC), J. Pach
(NYU and Hungarian Academy of Science), R. Pollack (NYU), R. Seidel
(Univ. of California at Berkeley), M. Sharir (NYU and Tel Aviv Univ.)
and J. Snoeyink (Stanford Univ.)
Business meeting
WEDNESDAY morning, 9:30-12:50, June 8, 1988
Chaired by David Kirkpatrick (University of British Columbia)
Path planning in 0/1 weighted regions with applications. L. Gewali
and A. Meng (Texas Instruments, Inc.), J. S. B. Mitchell (Cornell
Univ.), and S. Ntafos (Univ. of Texas at Dallas)
Motion planning in the presence of movable obstacles. G. Wilfong
(AT&T Bell Labs)
On the general motion planning problem with two degrees of freedom.
L. J. Guibas (DEC/SRC and Stanford Univ.), and M. Sharir (NYU and
Tel Aviv Univ.), and S. Sifrony (Tel Aviv Univ.)
On planning assemblies. B. K. Natarajan (Carnegie-Mellon Univ.)
Coffee Break: 10:50 am - 11:30 am
The complexity of planar compliant motion planning under uncertainty.
B. R. Donald (Cornell Univ.)
Coordinated motion planning for two independent robots. M. Sharir
(NYU and Tel Aviv Univ.) and S. Sifrony (Tel Aviv Univ.)
An automatic motion planning system for a convex polygonal mobile
robot in 2-dimensional polygonal space. K. Kedem (Tel Aviv Univ.)
and M. Sharir (NYU and Tel Aviv Univ.)
On maximum flows in polyhedral domains. J. S. B. Mitchell (Cornell
Univ.)
Lunch: 12:50 pm - 2:30 pm
WEDNESDAY afternoon, 2:30-4:10, June 8, 1988
Chaired by Richard Pollack (NYU)
Algorithms for vertical and orthogonal L_1 linear approximation of
points. P. Yamamoto (Kyushu Univ. and McGill Univ.), K. Kato (Kyushu
Univ.), K. Imai (Univ. of Tokyo), and H. Imai (Kyushu Univ.)
Skewed projections with an application to line stabbing in R~3.
J. W. Jaromczyk (Univ. of Kentuckey) and M. Kowaluk (Warsaw Univ.)
Arrangements of lines in 3-space: a data structure with applications.
M. McKenna and J. O'Rourke (The Johns Hopkins Univ.)
Triangles in space or building (and analyzing) castles in the air.
B. Aronov (NYU) and M. Sharir (NYU and Tel Aviv Univ.)
On continuous homotopic one layer routing. S. Gao (Uni. Saarbruecken),
M. Jerrum (Univ. of Edinburgh), M. Kaufmann, K. Mehlhorn, W. Ruelling,
and C. Storb (Univ. Saarbruecken)
End of Symposium
------------------------------------------------------------------------
CONFERENCE ORGANIZATION
Sponsors: SIGACT and SIGGRAPH
Conference Chair: Herbert Edelsbrunner, Department of Computer Science,
University of Illinois at Urbana-Champaign, Urbana, Illinois 61801,
(217) 333-6903, edels@p.cs.uiuc.edu
Program Chair: Bernard Chazelle, Department of Computer Science,
Princeton University, Priceton, New Jersey 08544,
(609) 452-5380.
Program Committee: Chanderjit Bajaj, Patrick Hanrahan, David
Kirkpatrick, Kurt Mehlhorn, Richard Pollack, V. Thomas Rajan, Richard
Riesenfeld, Raimund Seidel, Robert Tarjan, Christopher Van Wyk
------------------------------------------------------------------------
REGISTRATION AND BADGE INFORMATION
Please fill out this form and mail it to
University of Illinois at Urbana-Champaign
Accounting Business Office
Room 162, Administration Building
506 S. Wright Street
Urbana, IL 61801
Activity ID # 0128862141
UFAS ACCT # 1-3-62141-0660
Type or print exactly as it should appear for the name badge and
indicate your preferred term of address.
Name__________________ (first)_____________________ (middle init.)______
Social Security No._____________________________________________________
ACM membership No.______________________________________________________
Affiliation_____________________________________________________________
Address_________________________________________________________________
City__________________ State__________ Zip_________ Country_____________
Phone______________________ Net address_________________________________
Dietary restrictions: _____Kosher _____Vegetarian
REGISTRATION FEES
(before May 15) (After)
ACM and/or SIGGRAPH or
SIGACT member $140 $170
Non-member $170 $200
Full-time student $ 50 $ 70
Requests for refunds will be honored until March 8, 1988.
Method of payment (billing is available only to U.S.A. residents)
Check enclosed (make checks payable to University of Illinois)
Bill me at my organization address (SS No. required)________________
Bill my organization (FEIN No. required)_____________________________
Purchase order enclosed (FEIN No. required)__________________________
I prefer to charge on credit card: _____Visa _____Master Card
Card No._________________________________________________________
Expiration date__________________________________________________
Signature of card holder_________________________________________
FOR OFFICIAL USE ONLY
Method paid_____________________ Fee paid____________________________
Date paid_______________________ CRV #_______________________________
CS #____________________________ SI #________________________________
Acknowledgement_________________ Refund______________________________
________________________________________________________________________
ACCOMMODATION RESERVATION FORM
ACM Symposium on Computational Geometry, June 6-8, 1988
Please mail by May 1, 1988 to
Conferences and Institutes
Suite 202
302 East John Street
Champaign, Illinois 61820
(217) 333-2883
Accommodations required at Illinois Street Residence hall
Single US$ 19.00 per person per night plus tax
Twin US$ 13.00 per person per night plus tax
Arrival date________________________________ Time_______________________
Departure date______________________________ Time_______________________
Sharing room with_______________________________________________________
Name____________________________________________________________________
Affiliation_____________________________________________________________
Address_________________________________________________________________
_________________________________________________________________
City__________________ State__________ Zip_________ Country_____________
Phone___________________________________________________________________
∂08-Mar-88 1121 X3J13-mailer Re: X3J13 attendee list
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 8 Mar 88 11:21:23 PST
Received: from relay2.cs.net by RELAY.CS.NET id ae25704; 8 Mar 88 13:12 EST
Received: from csc.ti.com by RELAY.CS.NET id ak03153; 8 Mar 88 13:05 EST
Received: from home by tilde id AA09943; Tue, 8 Mar 88 10:43:52 CST
Received: by home id AA08325; Tue, 8 Mar 88 10:43:27 CST
Date: Tue, 8 Mar 88 10:43:27 CST
From: Ellen Waldrum <waldrum@home.csc.ti.com>
Message-Id: <8803081643.AA08325@home>
To: edsel!jlz@LABREA.STANFORD.EDU, paul%hpfclp@hplabs.hp.com,
x3j13@SAIL.STANFORD.EDU
Subject: Re: X3J13 attendee list
Jan,
I forgot. I will be going to dinner as well. BTW, David Bartley from TI
will be attending. I know he tried to send you a message.
-- Ellen
∂08-Mar-88 1339 X3J13-mailer X3 attendee list to date
Received: from HAL.CAD.MCC.COM ([128.62.1.126]) by SAIL.Stanford.EDU with TCP; 8 Mar 88 13:38:22 PST
Date: Tue, 8 Mar 88 15:11 CST
From: David D. Loeffler <Loeffler@MCC.COM>
Subject: X3 attendee list to date
To: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
cc: x3j13@sail.stanford.edu, Loeffler@MCC.COM
In-Reply-To: <8803012202.AA00420@sunvalleymall.lucid.com>
Message-ID: <19880308211108.3.LOEFFLER@HAL.CAD.MCC.COM>
Reply-To: Loeffler@MCC.COM
Postal-address: MCC, 3500 West Balcones Center Dr., Austin, TX 78759
Business-phone: (512) 338-3666
Date: Tue, 1 Mar 88 14:02:49 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Please let me know if your name isn't listed below and you are
attending the March meeting. I also need to know whether you
will be having lunch 3/16 and/or 3/17.
Add:
David D. Loeffler MCC
I have made all my travel arrangements. I will be having lunch on 3/16
and 3/17. I will pay on Wednesday.
-- David D. Loeffler
∂08-Mar-88 1340 STAGER@Score.Stanford.EDU End Quarter Grade Sheets
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Mar 88 13:40:36 PST
Date: Tue 8 Mar 88 13:34:01-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: End Quarter Grade Sheets
To: faculty@Score.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12380772400.36.STAGER@Score.Stanford.EDU>
The End Quarter Grade Sheets for Winter Quarter have arrived. I'll be
sending them out via courier today or tomorrow. Please let me know if you
haven't received yours by the end of the week.
Thanks.
Claire
P.S. They're due by noon Monday, March 21.
-------
∂09-Mar-88 0853 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu citicorp opportunity
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 88 08:52:21 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 9 Mar 88 08:45:50-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA09590; Wed, 9 Mar 88 08:50:06 PST
Date: Wed, 9 Mar 88 08:50:06 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8803091650.AA09590@Tenaya.stanford.edu>
To: faculty@score
Subject: citicorp opportunity
I received the following letter from Mr. Paul Glaser of Citicorp
Technology, Inc. Mr. Glaser has visited Stanford twice, talking
to Dean Gibbons and various department heads about the
opportunity he describes in the attached letter. People who are
interested in pursuing this matter might send me an e-mail
note, and I will forward the names to Glaser.
--------
March 7, 1988
Dear Nils:
This letter contains a brief outline of our program to predict the
financial services sector technology based business environment of the
future. With further distribution by you it could be used to
determine if other faculty are interested in discussing possible
participation in the program with me.
Citicorp is attempting to set up a highly skilled multi-disciplined
technical group who would help define what the financial services
sector products, services or business environment will be like in the
next ten to fifteen years as a result of technological change.
A prerequisite of such an undertaking is to cause this technical group
to understand, in some depth, the business functionality of the
financial services sector. With that knowledge and with their
understanding of available and future technology capabilities, they
would attempt to predict our future environment.
To achieve these goals Citicorp is recruiting participants from
Stanford, MIT and Carnegie Mellon who would spend from three to six
weeks this summer in an innovative program of lectures, simulations
and on-site training exercises in Citicorp facilities to become
familiar with the fundamentals of the financial services sector. The
training portion of the program is planned for the New York area.
All participants in the project would be expected to spend from two to
three days per month during the remainder of the year actively engaged
in the process of meeting the goals of the program. Meetings and
ongoing relationships between all participants are planned through a
combination of videoteleconferencing, meetings and a continuous
electronic conference.
Citicorp recognizes that an active relationship with Universities such
as Stanford, MIT and Carnegie Mellon will be extremely beneficial
during this phase of the program and afterwards. The exact nature of
this involvement needs definition but we expect it to be in the form
of additional staff expertise and possible research programs
recommended by the participants.
We also believe that the program will lead to many future activities
such as projects to develop systems and applications allowing us to
gain a competitive advantage with the strategic knowledge gained. For
those participants who desire to remain involved we would welcome the
opportunity to develop a more permanent relationsihp as the program
proceeds.
I value your interest in our program and appreciate the time you have
given and your willingness to distribute the program outline contained
herein. Any further suggestions you might have would be appreciated
and if you have any time, either now or in the future, to participate
personally in the program we would welcome your involvement.
Warmest regards,
Paul
∂09-Mar-88 0942 @Score.Stanford.EDU:cheriton@Pescadero.stanford.edu Noise annoys
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 88 09:42:19 PST
Received: from Pescadero by SCORE.STANFORD.EDU with TCP; Wed 9 Mar 88 09:35:50-PST
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA01404; Wed, 9 Mar 88 09:40:49 PST
Date: Wed, 9 Mar 88 09:40:49 PST
From: "David Cheriton" <cheriton@pescadero.stanford.edu>
Message-Id: <8803091740.AA01404@Pescadero>
To: faculty@score.stanford.edu
Subject: Noise annoys
Are there others that are annoyed like me with the long-running
noise-making of repeated digging and filling going on behind MJH.
That area was redone last summer with great noise and commotion.
Recently, the O&M people decided to dig it up again.
Unless I am alone in these sentiments, I would like the Chairman to sent
a letter of complaint to the university. I think we deserve quiet offices
in which to work. The current craziness encourages me
to avoid my office; is that what the univesity wants?
∂09-Mar-88 0949 GOLDBERG@Score.Stanford.EDU Re: Noise annoys
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 88 09:48:58 PST
Date: Wed 9 Mar 88 09:42:16-PST
From: Andrew Goldberg <GOLDBERG@Score.Stanford.EDU>
Subject: Re: Noise annoys
To: cheriton@Pescadero.Stanford.EDU
cc: faculty@Score.Stanford.EDU
In-Reply-To: <8803091740.AA01404@Pescadero>
Message-ID: <12380992355.15.GOLDBERG@Score.Stanford.EDU>
I'd like to join to David's complaint. I also would like to add that
whatever is being done under my window, is very badly planned.
The pipes (or whatever it is) should be put in BEFORE the asphalt,
not after!
--Andy
-------
∂09-Mar-88 1019 GENESERETH@Score.Stanford.EDU Re: Noise annoys
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 88 10:18:59 PST
Date: Wed 9 Mar 88 10:10:14-PST
From: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Subject: Re: Noise annoys
To: GOLDBERG@Score.Stanford.EDU
cc: cheriton@Pescadero.Stanford.EDU, faculty@Score.Stanford.EDU
In-Reply-To: <12380992355.15.GOLDBERG@Score.Stanford.EDU>
Message-ID: <12380997447.50.GENESERETH@Score.Stanford.EDU>
Folks,
I wholeheartedly agree with David and Andy. I have lost att least a
man-month of use of my office since last fall due to the digging. I think'
the university needs to decide whether it is worth it to diminish the
output of many of its faculty, staff, amnd students or to pay the
extra amont necessary to get the job done in off hours. Th problem
is that, without complaints, the universityu may assume that there
is no problem. Nils, a STRONGLY worded-complaint, please!
mrg
-------
∂09-Mar-88 1026 ULLMAN@Score.Stanford.EDU noise
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 88 10:25:00 PST
Date: Wed 9 Mar 88 10:11:17-PST
From: Jeffrey D. Ullman <ULLMAN@Score.Stanford.EDU>
Subject: noise
To: faculty@Score.Stanford.EDU
Message-ID: <12380997638.47.ULLMAN@Score.Stanford.EDU>
As usual, I disagree with David. The noise out back drowns
out the buzzing of the workstation in my office, and I find it
conducive to work.
---jeff
-------
∂09-Mar-88 1052 @Score.Stanford.EDU:WIEDERHOLD@SUMEX-AIM.Stanford.EDU Re: noise
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 88 10:52:02 PST
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 9 Mar 88 10:45:25-PST
Date: Wed, 9 Mar 88 10:48:43 PST
From: Gio Wiederhold <WIEDERHOLD@SUMEX-AIM.Stanford.EDU>
Subject: Re: noise
To: ULLMAN@Score.Stanford.EDU
cc: faculty@Score.Stanford.EDU
In-Reply-To: <12380997638.47.ULLMAN@Score.Stanford.EDU>
Message-ID: <12381004452.83.WIEDERHOLD@SUMEX-AIM.Stanford.EDU>
This time I agree with Dave rather than with Jeff. But then I find a noisy
workstation also unacceptable in my office.
If work must be carried out out, doing it during dead and finals week is
particularly annoying. Gio
-------
∂09-Mar-88 1057 @Score.Stanford.EDU:wheaton@athena.stanford.edu Noise annoys
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 88 10:57:35 PST
Received: from athena.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 9 Mar 88 10:46:09-PST
Received: by athena.stanford.edu (4.0/SMI-DDN)
id AA01018; Wed, 9 Mar 88 10:50:34 PST
Date: Wed, 9 Mar 88 10:50:34 PST
From: wheaton@athena.stanford.edu (George Wheaton)
Message-Id: <8803091850.AA01018@athena.stanford.edu>
To: cheriton@pescadero.stanford.edu
Cc: faculty@score.stanford.edu
In-Reply-To: "David Cheriton"'s message of Wed, 9 Mar 88 09:40:49 PST <8803091740.AA01404@Pescadero>
Subject: Noise annoys
David et al,
We received a letter from Facilities apologizing for the commotion.
It seems that during a routine sewer cleaning job, their hose got
stuck. In the process of removing it, the crew discovered that the
sewer line was falling apart. That discovery may lead to others, all
of which will have to be replaced. If all goes well, you soon will
benefit from a nice new sewer system, but, meanwhile, more commotion.
GW
∂09-Mar-88 1102 GENESERETH@Score.Stanford.EDU noise
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 88 11:02:00 PST
Date: Wed 9 Mar 88 10:48:45-PST
From: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Subject: noise
To: faculty@Score.Stanford.EDU
Message-ID: <12381004458.50.GENESERETH@Score.Stanford.EDU>
Folks,
I wholeheartedly agree with David and Andy. I have lost att least a
man-month of use of my office since last fall due to the digging. I think'
the university needs to decide whether it is worth it to diminish the
output of many of its faculty, staff, amnd students or to pay the
extra amont necessary to get the job done in off hours. Th problem
is that, without complaints, the universityu may assume that there
is no problem. Nils, a STRONGLY worded-complaint, please!
mrg
-------
∂09-Mar-88 1107 @Score.Stanford.EDU:DCL@SAIL.Stanford.EDU Noise
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 88 11:07:17 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 9 Mar 88 10:54:20-PST
Date: 09 Mar 88 1057 PST
From: David Luckham <DCL@SAIL.Stanford.EDU>
Subject: Noise
To: faculty@SCORE.STANFORD.EDU
This noise about noise annoys more than the noise annoys
-D
∂09-Mar-88 1111 TAJNAI@Score.Stanford.EDU Re: Noise annoys
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 88 11:11:17 PST
Date: Wed 9 Mar 88 10:54:57-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Re: Noise annoys
To: wheaton@athena.Stanford.EDU, cheriton@Pescadero.Stanford.EDU
cc: faculty@Score.Stanford.EDU
In-Reply-To: <8803091850.AA01018@athena.stanford.edu>
Message-ID: <12381005587.18.TAJNAI@Score.Stanford.EDU>
I recommend the light-weight ear muffs to muffle the sound.
ERL was re-roofed recently (the pounding caused the air vents to
fall) and it helped. Unfortunately, you can still hear the phone ring.
I first purcased them for the machine room -- they are the light-
weight yellow ones. I have a pair at home and one in my office.
About $10 each.
Carolyn
-------
∂09-Mar-88 1115 @Score.Stanford.EDU:tom@polya.stanford.edu Noise annoys
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 88 11:15:50 PST
Received: from polya.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 9 Mar 88 11:00:27-PST
Received: by polya.stanford.edu (5.54/inc-1.2)
id AA10056; Wed, 9 Mar 88 11:04:58 PST
Date: Wed, 9 Mar 88 11:04:58 PST
From: tom@polya.stanford.edu (Tom Dienstbier)
Message-Id: <8803091904.AA10056@polya.stanford.edu>
To: cheriton@pescadero.stanford.edu
Cc: faculty@score.stanford.edu
In-Reply-To: "David Cheriton"'s message of Wed, 9 Mar 88 09:40:49 PST <8803091740.AA01404@Pescadero>
Subject: Noise annoys
The reason of the commotion was because of a plugged up sewer line.
O&M did try and fix it by sending down a snake/router to unplug the line and
quickly got the bit stuck. They then tried it from the other end
and got another bit stuck. Then they sent a camera down the tube so they
could see what was really happening and decided, yes indeed, it is really
plugged up with two broken router's and other things. The only recourse at
this point was to dig it up which is what the did. They should be finished
now with the loud equipment. Only clean-up and replanting is left.
tom
∂09-Mar-88 1120 @Score.Stanford.EDU:FEIGENBAUM@SUMEX-AIM.Stanford.EDU Re: noise
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 88 11:19:53 PST
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 9 Mar 88 11:01:06-PST
Date: Wed, 9 Mar 88 11:03:47 PST
From: Edward Feigenbaum <FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
Subject: Re: noise
To: WIEDERHOLD@SUMEX-AIM.Stanford.EDU, ULLMAN@Score.Stanford.EDU
cc: faculty@Score.Stanford.EDU
In-Reply-To: <12381004452.83.WIEDERHOLD@SUMEX-AIM.Stanford.EDU>
Message-ID: <12381007194.11.FEIGENBAUM@SUMEX-AIM.Stanford.EDU>
Overe the past month I have need to make rather intensive use of my
MJH office for a great deal of book writing, and have found it simply
impossible to do because of the incredible noise. I had to shift to home
to get the work done, which was not satisfactory.
Ed
-------
∂09-Mar-88 1133 @Score.Stanford.EDU:wheaton@athena.stanford.edu Search Committee
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 88 11:33:26 PST
Received: from athena.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 9 Mar 88 11:18:34-PST
Received: by athena.stanford.edu (4.0/SMI-DDN)
id AA01065; Wed, 9 Mar 88 11:22:48 PST
Date: Wed, 9 Mar 88 11:22:48 PST
From: wheaton@athena.stanford.edu (George Wheaton)
Message-Id: <8803091922.AA01065@athena.stanford.edu>
To: ac@score, eustis@sierra, lecturers@score, bureaucrats@sushi, chang@sushi,
fuki@sushi
Subject: Search Committee
I'm sure all of you know by now that Stuart Reges has decided to join
NeXT, Steve Jobs' new company. From all indications, it is an
exciting opportunity for Stuart, but it leaves the Department without
an Assistant Chairman for Education. Nils has appointed Roy Jones as
Acting Assistant Chairman, but he also has asked me to form a search
committee to find and recommend suitable candidates for a permanent
position. The committee should have representatives from CSD faculty,
CSD lecturers, the Dean's office, and students - both graduate and
undergraduate.
I am now in the process of forming the committee; if any of you are
interested and willing to serve, please let me know as soon as you
can. This is an important position in the Department, and it deserves
a dedicated committee.
George
∂09-Mar-88 1325 @Score.Stanford.EDU:tom@polya.stanford.edu [tom: LPS40/DOVER moves]
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 88 13:25:33 PST
Received: from polya.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 9 Mar 88 13:18:42-PST
Received: by polya.stanford.edu (5.54/inc-1.2)
id AA12457; Wed, 9 Mar 88 13:23:11 PST
Date: Wed, 9 Mar 88 13:23:11 PST
From: tom@polya.stanford.edu (Tom Dienstbier)
Message-Id: <8803092123.AA12457@polya.stanford.edu>
To: faculty@score.stanford.edu, staff@score.stanford.edu
Subject: [tom: LPS40/DOVER moves]
As some of you may have noticed, we have moved the new LPS40 laser printer
into room 221(old Dover room). This coming Monday, we plan to de-commission
the Dover. The Dover printer will then be moved to the 5th floor(storage area)
to be used as a spare parts machine for the 4th floor Dover(called Rover). Our
plan is to re-name Rover to be called Dover.
The name of the new LPS40 is SZEGO
To print to this printer from the 20's, change the set location in your
login.cmd file to be set loc MJH::
Then use the "print" command. @print filename
To print from POLYA, use lpr filename
To print from other UNIX machines, use lpr -Pprintername filename or
whatever works!
For additional help in using SZEGO contact Dan Kolkowitz, Stu Grossman, or
James Wilson.
tom
∂09-Mar-88 1918 LOGMTC-mailer Logic lunch
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 9 Mar 88 19:18:46 PST
Received: by csli.stanford.edu (3.2/4.7); Wed, 9 Mar 88 19:22:00 PST
Date: Wed 9 Mar 88 19:21:59-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: Logic lunch
To: Logic@csli.stanford.edu
Message-Id: <573967319.0.SF@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@CSLI.Stanford.EDU>
Monday's discussion will be continued by Natarajan Shankar with an outline
of a (machine-checked) proof of the first incompleteness theorem that
was formalized in Boyer and Moore's quantifier-free theory of total
recursive functions.
Same place, same time.
-------
∂09-Mar-88 2245 SHOHAM@Score.Stanford.EDU Re: Noise annoys
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 88 22:45:35 PST
Date: Wed 9 Mar 88 22:40:11-PST
From: Yoav Shoham <SHOHAM@Score.Stanford.EDU>
Subject: Re: Noise annoys
To: cheriton@Pescadero.Stanford.EDU
cc: faculty@Score.Stanford.EDU
In-Reply-To: <8803091740.AA01404@Pescadero>
Message-ID: <12381133970.13.SHOHAM@Score.Stanford.EDU>
I'm in your situation, but two floors closer to the noise.
In short, I agree 100%.
Yoav
-------
∂10-Mar-88 0858 @Score.Stanford.EDU:ball@navajo.stanford.edu Computer Facilities Rates
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 88 08:58:11 PST
Received: from navajo.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 10 Mar 88 08:51:43-PST
Received: by navajo.stanford.edu; Thu, 10 Mar 88 08:51:58 PST
Date: Thu, 10 Mar 88 08:51:58 PST
From: James E. Ball <ball@navajo.stanford.edu>
Subject: Computer Facilities Rates
To: Faculty@score.stanford.edu
Below are the rates which became effective on Feb 2nd. The new rate sheet
was required to include POLYA. I held off publishing the sheet until a
decision was reached on how POLYA charges for the users moving off SUSHI
were to be handled.
COMPUTER SCIENCE DEPARTMENT COMPUTER FACILITIES
SERVICE CENTER RATES
EFFECTIVE 2/1/88
TIME WEEKDAY WEEKEND
--------- --------- ---------
"A" RATES = 100% 0000-0800 C C
"B" RATES = 66.67% OF "A" RATE 0800-1300 A C
"C" RATES = 33.33% OF "A" RATE 1300-1800 A B
1800-2400 B C
-------TIME OF DAY RATES---------
"A" RATES "B" RATES "C" RATES FIXED RATES
--------- --------- --------- -----------
Score Computer
Account charge Accts @ 5.00
Connect time hours @ 1.00 0.67 0.33
CPU time Minutes @ 2.85 1.90 0.95
Disk space Mbits/Mo @ 2.95
Sail Computer
Account charge Accts @ 5.00
Connect time hours @ 1.00 0.67 0.33
CPU time Minutes @ 4.20 2.80 1.40
Disk space Mbits/Mo @ 4.00
Navajo Computer
Account charge Accts @ 5.00
Connect time hours @ 1.00 0.67 0.33
CPU time Minutes @ 1.89 1.26 0.63
Disk space Mbits/Mo @ 2.94
Labrea Computer
Account charge Accts @ 5.00
Connect time hours @ 1.00 0.67 0.33
CPU time Minutes @ 1.75 1.17 0.58
Disk space Mbits/Mo @ 1.25
Jeeves Fileserver
Account charge Accts @ 5.00
Connect time hours @ 0.00
CPU time Minutes @ 0.00
Disk space Mbits/Mo @ 2.10
Polya
Account charge Accts @ 5.00
Connect time hours @ 1.00 0.67 0.33
CPU time Minutes @ 5.66 3.77 1.89
Disk space Mbits/Mo @ 2.00
Printers
Dovers pages @ 0.09
Imagen/Apple pages @ 0.09
Boise pages @ 0.07
Phototypsetter
Page charges @ 4.50
Ethernet Maintenance
Monthly charges
Workstations & Minis 33.00
Mainframes & Bridges 330.00
Sushi Computer
Monthly charges
Maint. & Depr. 8,708.86
VAX-75- Computer Maint.
Monthly charges
Basic VAX-750 475.00
RA81 Disk Drive 100.00
Kennedy 9300 Tape 200.00
Fujitsu M2351 Disk 50.00
TU78 100.00
CDC 9766 Controller 100.00
Emulex SC758 66.00
8 line term MUX 16.00
∂10-Mar-88 1214 P.PROMETHEUS@MACBETH.STANFORD.EDU ssp club
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 10 Mar 88 12:14:24 PST
Received: from russell.stanford.edu by csli.stanford.edu (3.2/4.7); Thu, 10 Mar 88 12:16:56 PST
Received: from MACBETH.STANFORD.EDU by russell.stanford.edu (3.2/4.7); Thu, 10 Mar 88 12:18:17 PST
Date: Thu 10 Mar 88 12:11:55-PST
From: Reid Hoffman <P.PROMETHEUS@MACBETH.STANFORD.EDU>
Subject: ssp club
To: ssp-faculty@RUSSELL.STANFORD.EDU
Message-Id: <12381281742.303.P.PROMETHEUS@MACBETH.STANFORD.EDU>
Tentatively, the following dates are being considered for the SSP club
meeting times:
(Strong Preference) 3:15 Friday Afternoon
(Less) 12:00 Lunch Thursday.
I think more off-campus faculty would be able to make the friday time, and
it also allows for more time for interesting programs. If you have any
feedback, please let me know.
thanks
reid
-------
∂10-Mar-88 1526 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: nice looking graphs
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 88 15:25:57 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Thu 10 Mar 88 15:06:44-PST
Received: by lindy.stanford.edu; Thu, 10 Mar 88 11:29:44 PST
Received: by Forsythe.Stanford.EDU; Thu, 10 Mar 88 15:09:14 PST
Received: by BYUADMIN (Mailer X1.25) id 6364; Thu, 10 Mar 88 16:07:35 MST
Date: Thu, 10 Mar 88 16:56:03 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"C. Papadimitriou" <PAPA@score.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "C. Papadimitriou" <PAPA@score.stanford.edu>
Subject: Re: nice looking graphs
To: Local Distribution <aflb.tn@sushi.stanford.edu>
I recall a paper by Lipton and somebody in Bell Labs on the subject.
Also, a lot of papers on nice layouts of trees...
---Christos
∂10-Mar-88 1556 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Matching
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 88 15:56:35 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Thu 10 Mar 88 15:14:36-PST
Received: by lindy.stanford.edu; Thu, 10 Mar 88 11:37:39 PST
Received: by Forsythe.Stanford.EDU; Thu, 10 Mar 88 15:17:15 PST
Received: by BYUADMIN (Mailer X1.25) id 6637; Thu, 10 Mar 88 16:15:35 MST
Date: Thu, 10 Mar 88 16:58:55 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
jose <A427%EMDUCM11.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: jose <A427%EMDUCM11.BITNET@forsythe.stanford.edu>
Subject: Matching
To: Local Distribution <aflb.tn@sushi.stanford.edu>
Dose anybody have information about the vehicle routing problem and Matching
problem?
Thanks
Jose
∂10-Mar-88 1614 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: nice looking graphs
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 88 16:14:37 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Thu 10 Mar 88 15:36:43-PST
Received: by lindy.stanford.edu; Thu, 10 Mar 88 12:00:05 PST
Received: by Forsythe.Stanford.EDU; Thu, 10 Mar 88 15:29:27 PST
Received: by BYUADMIN (Mailer X1.25) id 6747; Thu, 10 Mar 88 16:24:21 MST
Date: Thu, 10 Mar 88 17:02:12 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
James R Drinkwater <jd%csd4.milw.wisc.edu@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: James R Drinkwater <jd%csd4.milw.wisc.edu@forsythe.stanford.edu>
Subject: Re: nice looking graphs
To: Local Distribution <aflb.tn@sushi.stanford.edu>
In article <8803081440.AA28816@jade.berkeley.edu> TheoryNet List <THEORYNT%NDSUV
>This is in reply to Dr. Harel's query on nice-looking graphs:
>
>I remember seeing an article in ACTA INFORMATICA (at most 5
>years ago but probably more recently) on this subject.
>Unfortunately I can't remember the author(s).
>
I believe the reference you mean is Chiba et al., "Drawing plane graphs
nicely," Acta Informatica, 22, 187-201, 1985.
Jim Drinkwater
∂10-Mar-88 1628 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Rochester Connectionist Simulator update
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 88 16:28:04 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Thu 10 Mar 88 15:48:03-PST
Received: by lindy.stanford.edu; Thu, 10 Mar 88 12:11:09 PST
Received: by Forsythe.Stanford.EDU; Thu, 10 Mar 88 15:48:30 PST
Received: by BYUADMIN (Mailer X1.25) id 6947; Thu, 10 Mar 88 16:46:34 MST
Date: Thu, 10 Mar 88 17:05:18 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
goddard%CS.ROCHESTER.EDU@forsythe.stanford.edu
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: goddard%CS.ROCHESTER.EDU@forsythe.stanford.edu
Subject: Rochester Connectionist Simulator update
To: Local Distribution <aflb.tn@sushi.stanford.edu>
(my apologies if this message is sent twice)
The Rochester Connectionist Simulator is available from:
Rose Peet
Department of Computer Science
University of Rochester
Rochester, NY 14627.
rose@cs.rochester.edu
...!seismo!rochester!rose
There is a licence to sign, and a distribution fee. Currently
distribution is via tape only, anonymous ftp may become available at
some indeterminate point in the future. The package is written in C,
runs under UNIX, and has a graphics package which runs under Suntools.
It is currently in use at several dozen sites and is described in the
February issue of the CACM. The simulation system is highly general
and flexible, placing no restrictions on network architecture, unit
activation functions and data, or learning algorithms.
A new version, 4.1, will be releases shortly. Version 4.1 includes
facilities to selectively delete links and sites, with garbage
collection; capability for integration with Kyoto Common Lisp and
Scheme, allowing the simulator to be controlled from those packages;
dynamic reloading of activation and other functions into a running
simulator, with access to global variables from the interface; and the
ability to associate a delay with each link.
An X-windows graphics package is under development.
A mailing list for simulator users will be started shortly.
For more information, licence, distribution details, contact Rose Peet
at the address above.
Nigel Goddard
∂10-Mar-88 1645 CHANDLER@Score.Stanford.EDU faculty meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 88 16:43:25 PST
Date: Thu 10 Mar 88 16:33:27-PST
From: Joyce R. Chandler <CHANDLER@Score.Stanford.EDU>
Subject: faculty meeting
To: faculty@Score.Stanford.EDU
cc: chandler@Score.Stanford.EDU
Message-ID: <12381329354.43.CHANDLER@Score.Stanford.EDU>
ADVANCE NOTICE...please put on your calendar. Faculty meeting scheduled
for March 29, 1988 at 2:15 - 4:00 in MJH-146.
Please send me any suggestions for agenda items.
Thanks.
-------
∂10-Mar-88 1705 TAJNAI@Score.Stanford.EDU LSI Logic
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 88 17:04:08 PST
Date: Thu 10 Mar 88 16:58:05-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: LSI Logic
To: faculty@Score.Stanford.EDU
Message-ID: <12381333837.42.TAJNAI@Score.Stanford.EDU>
LSI Logic is a new Forum company. It seems that one of you sent me
a message saying that you had been involved with LSI Logic and would
be happy to be the liaison. Dr. Peng Ang is our contact with the
Palo Alto office. I believe it was one of the new faculty members,
but I cannot find any note in either computer or hardcopy files.
Please send msg if you are the one.
Carolyn
-------
∂11-Mar-88 1056 TAJNAI@Score.Stanford.EDU [Joanne Chequer <CHEQUER@Sierra.Stanford.EDU>: SUNRISE CLUB MEETS MARCH 22]
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 88 10:54:43 PST
Date: Fri 11 Mar 88 10:45:53-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: [Joanne Chequer <CHEQUER@Sierra.Stanford.EDU>: SUNRISE CLUB MEETS MARCH 22]
To: faculty@Score.Stanford.EDU, phd@Score.Stanford.EDU, ras@Score.Stanford.EDU
Message-ID: <12381528225.20.TAJNAI@Score.Stanford.EDU>
Date: Fri 11 Mar 88 10:42:59-PST
From: Joanne Chequer <CHEQUER@Sierra.Stanford.EDU>
Subject: SUNRISE CLUB MEETS MARCH 22
To: tajnai@SCORE.STANFORD.EDU
Hello! The Sunrise CLub will meet on Tuesday, March 22 at 7:30 a.m.
at the Oak Lounge West, Tresidder Union. Dr. Edward Rubenstein,
professor of medicine (clinical), will speak on an exciting
biotechnological subject, "Intravenous Coronary Angiography with
Synchrotron X-Rays."
So that we can plan for breakfast, would you please R.S.V.P.
to Carolyn Tajnai at Tajnai@Score by Friday, March 18?
THANK YOU!
-------
∂11-Mar-88 1410 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU supercomputer center comments
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 88 14:10:42 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 11 Mar 88 13:49:37-PST
Date: 11 Mar 88 1353 PST
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: supercomputer center comments
To: faculty@Score.Stanford.EDU
The nsf bill including support for supercomputer centers
is scheduled for "markup" in the House of Representatives
on March 29. There are to be two panels of testimony
on the subject before then - apparently all from enthusiasts.
I talked, on the advice of a Congress hacker friend, with
Grace Ostenso, the staff director of the relevant subcommittee.
She told me that the only possibility for input would be a
statement.
I propose a statement that states that support for researchers, not for
supercomputing, is the dominant need in computer science research.
I would welcome messages offering to help draft such a statement
or to sign it.
∂11-Mar-88 1526 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Larry Rosenberg
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 88 15:26:50 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 11 Mar 88 15:20:44-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA11734; Fri, 11 Mar 88 15:25:06 PST
Date: Fri, 11 Mar 88 15:25:06 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8803112325.AA11734@Tenaya.stanford.edu>
To: faculty@score
Subject: Larry Rosenberg
Larry Rosenberg from NSF's Information Science Division will be the
guest of Prof Paul Milgram of the Economics Department on Friday,
March 25, 1988. He (Larry) would like to meet with interested
computer science people in the morning. Anyone within earshot of this
msg who would like to talk with Larry should get in touch with Paul
Milgram, ext. 3-3397.
-Nils
∂14-Mar-88 0914 LOGMTC-mailer Reminder
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 14 Mar 88 09:14:34 PST
Received: from russell.stanford.edu by csli.stanford.edu (3.2/4.7); Mon, 14 Mar 88 09:17:52 PST
Received: from localhost by russell.stanford.edu (3.2/4.7); Mon, 14 Mar 88 09:19:20 PST
To: logic@russell.stanford.edu
Subject: Reminder
Date: Mon, 14 Mar 88 09:19:17 PST
From: Jon Barwise <barwise@russell.stanford.edu>
Logic lunch today. Shankar will talk about his work on Godel's Thm and
the Boyer Moore Thm Prover.
∂14-Mar-88 1031 CHANDLER@Score.Stanford.EDU 3/15/88 faculty lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Mar 88 10:30:58 PST
Date: Mon 14 Mar 88 10:15:52-PST
From: Joyce R. Chandler <CHANDLER@Score.Stanford.EDU>
Subject: 3/15/88 faculty lunch
To: faculty@Score.Stanford.EDU
Message-ID: <12382309192.15.CHANDLER@Score.Stanford.EDU>
The faculty lunch on Tuesday, March 15 does not have a scheduled topic, and
Nils will not be able to attend. Lunch will go on as usual; faculty are
invited to come and chat with each other. Please note that there will not
be a faculty lunch on Tuesday, March 22. Regular CSD/CSL faculty lunches
for Spring quarter will resume on Tuesday, March 29.
-------
∂14-Mar-88 1058 FACIL-mailer Apple/DEC/Stanford Brainstorming Session
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Mar 88 10:58:06 PST
Date: Mon, 14 Mar 88 10:54:14 PST
From: TC Rindfleisch <Rindfleisch@SUMEX-AIM.Stanford.EDU>
Subject: Apple/DEC/Stanford Brainstorming Session
To: KSL@SUMEX-AIM.Stanford.EDU, Faculty@Score.Stanford.EDU,
Facil@SAIL.Stanford.EDU
cc: Rindfleisch@SUMEX-AIM.Stanford.EDU
Message-ID: <12382316176.15.RINDFLEISCH@SUMEX-AIM.Stanford.EDU>
I just found out about a "brainstorming" meeting tomorrow to discuss ideas
about what Apple and DEC could/should do in the way of joint projects at
Stanford. Sorry for the short notice but let me know if you have ideas to
raise. If you want to attend, the meeting will be on Tuesday, March 15, at
2:00 pm in Sweet Hall 303.
Tom R.
-------
∂14-Mar-88 1059 @Score.Stanford.EDU:RINDFLEISCH@SUMEX-AIM.Stanford.EDU Apple/DEC/Stanford Brainstorming Session
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Mar 88 10:59:43 PST
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 14 Mar 88 10:54:02-PST
Date: Mon, 14 Mar 88 10:54:14 PST
From: TC Rindfleisch <Rindfleisch@SUMEX-AIM.Stanford.EDU>
Subject: Apple/DEC/Stanford Brainstorming Session
To: KSL@SUMEX-AIM.Stanford.EDU, Faculty@Score.Stanford.EDU,
Facil@SAIL.Stanford.EDU
cc: Rindfleisch@SUMEX-AIM.Stanford.EDU
Message-ID: <12382316176.15.RINDFLEISCH@SUMEX-AIM.Stanford.EDU>
I just found out about a "brainstorming" meeting tomorrow to discuss ideas
about what Apple and DEC could/should do in the way of joint projects at
Stanford. Sorry for the short notice but let me know if you have ideas to
raise. If you want to attend, the meeting will be on Tuesday, March 15, at
2:00 pm in Sweet Hall 303.
Tom R.
-------
∂14-Mar-88 1235 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: nice looking graphs
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Mar 88 12:35:30 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Mon 14 Mar 88 12:28:52-PST
Received: by lindy.stanford.edu; Mon, 14 Mar 88 08:52:58 PST
Received: by Forsythe.Stanford.EDU; Mon, 14 Mar 88 12:32:49 PST
Received: by BYUADMIN (Mailer X1.25) id 6312; Mon, 14 Mar 88 13:32:55 MST
Date: Mon, 14 Mar 88 13:33:53 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Mike A. Gigante"
<munnari!moncskermit!goanna!cidam!mg@uunet.uu.net>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Mike A. Gigante"
<munnari!moncskermit!goanna!cidam!mg@uunet.uu.net>
Subject: Re: nice looking graphs
To: Local Distribution <aflb.tn@sushi.stanford.edu>
If you are a Common Lisp programmer, you could obtain the ISI grapher.
The ISI grapher performs a "nice" layout of graphs; I think that is is
provided as a set of routines. This was announced on usenet about 6-12 months
ago. I have some documentation, I can chase it up if there is interest
(or contact ISI!)
Mike Gigante
∂14-Mar-88 1339 barwise@russell.stanford.edu URO Grants
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 14 Mar 88 13:39:38 PST
Received: from russell.stanford.edu by csli.stanford.edu (3.2/4.7); Mon, 14 Mar 88 13:38:36 PST
Received: from localhost by russell.stanford.edu (3.2/4.7); Mon, 14 Mar 88 13:40:07 PST
To: ssp-students@russell.stanford.edu, csli-ssp@russell.stanford.edu
Cc: ssp-faculty@russell.stanford.edu
Subject: URO Grants
Date: Mon, 14 Mar 88 13:40:03 PST
From: Jon Barwise <barwise@russell.stanford.edu>
--------
There is a major undergrad research competetion, open only to SU
undergrads, that some ssp students should apply for. The studetn
award is up to $2500. Faculty sponsors get $500. These are for
projects that extend over at least 3 quarters. The dealine is April
1.
More information is available in 62G or 122 Sweet Hall.
∂14-Mar-88 1632 @Score.Stanford.EDU:wheaton@athena.stanford.edu
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Mar 88 16:30:24 PST
Received: from athena.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 14 Mar 88 16:25:33-PST
Received: by athena.stanford.edu (4.0/SMI-DDN)
id AA04516; Mon, 14 Mar 88 16:00:25 PST
Date: Mon, 14 Mar 88 16:00:25 PST
From: wheaton@athena.stanford.edu (George Wheaton)
Message-Id: <8803150000.AA04516@athena.stanford.edu>
To: ac@score, sjg@sail, val@sail, ok@sail, brown@sumex, clancey@sumex,
engelmore@sumex
bhayes-roth@sumex rindfleisch@sumex nii@sumex
Subject: Retreat
BCC: wheaton
ANNOUNCEMENT AND POLL---FACULTY RETREAT
It appears that the best time to hold the much-discussed CSD/CSL
faculty retreat is from Friday evening, May 27th through, say, Sunday
early afternoon, May 29 (Memorial Day weekend). Although retreat
sites are filling up rapidly for the Spring, we have a "hold" on
Chaminade---a fine place for this retreat in Santa Cruz. They have
single and double occupancy rooms, a fine meal service, meeting room
facilities, tennis courts, hiking paths, gym and fitness center, etc.
I regard Chaminade so far as an excellent default---which we will use
unless something obviously better (and less expensive) turns up.
The price for all of this (meals included) is $135 per person per day
plus tax and a 15% service charge (double occupancy); or $175 per
person per day (single occupancy). The Department will pay the double
occupancy rate; if individuals would like single occupancy, they can
either pay the difference ($80 per person--assuming two nights) in
cash or check or give us a charge number to which to bill the
difference.
The tentative agenda (suggestions welcomed) for the retreat, which
will be open to all CSD/CSL faculty and Senior Research Associates
(plus courtesy faculty) is:
Friday evening (after dinner): Arrival and "warm-up" session.
Saturday (all day): Technical talks by us to us.
Saturday (evening): Unscheduled time to engage colleagues
in technical discussions.
Sunday: More talks and wrap-up.
To hold Chaminade, we will need to sign up with them within the
next 10 days or so, and we will need to send a deposit and tell
them how many of us there will be. So, we need the following
information asap.
1. The probability that I will go on this retreat is ____%
(This number must become either 0 or 100% by 1 April 1988.)
Following to be answered only by people whose probability of attending
is above 75%:
2. (If applicable): I would prefer a single-occupancy room and will
arrange to pay the difference between its price and that of double
occupancy.
3. I want to give a talk at this retreat about a subject I am
working on or otherwise interested in. Title:________________
______________. Besides the usual O/H projector, which will
be there, I need the following A/V equipment:_________________
_________________.
In addition, Do you think we should invite our "Consulting Professors"?
If invited, they should probably be asked to pay their expenses, since
the primary purpose of this retreat (as originally suggested by
Don Knuth and subscribed to by most of us) is for the faculty of the
Department to get to know what each other is doing.
Please respond to George Wheaton (wheaton@athena) as soon as you
can.
Thanks,
Nils
-------
∨
∂16-Mar-88 1227 barwise@russell.stanford.edu Postponement of deadline
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 16 Mar 88 12:25:40 PST
Received: from russell.stanford.edu by csli.stanford.edu (3.2/4.7); Wed, 16 Mar 88 11:47:06 PST
Received: from localhost by russell.stanford.edu (3.2/4.7); Wed, 16 Mar 88 11:48:37 PST
To: ssp-students@russell.stanford.edu
Cc: csli-ssp@russell.stanford.edu, ssp-faculty@russell.stanford.edu
Subject: Postponement of deadline
Date: Wed, 16 Mar 88 11:48:33 PST
From: Jon Barwise <barwise@russell.stanford.edu>
The only point of having the application of the internship deadline when it
was was to be able to make decisions early and so help students plan their
summer. In the past couple of days I have heard enough complaints about
the deadline that I have decided it should be postponed for a week, to
April 4. Sorry if this change of plans comes too late for some of you
to plan your time maximally.
Jon
∂16-Mar-88 1311 @Score.Stanford.EDU:BUCHANAN@SUMEX-AIM.Stanford.EDU Departure
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 88 13:11:20 PST
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 15 Mar 88 07:16:26-PST
Date: Tue, 15 Mar 88 07:11:13 PST
From: Bruce Buchanan <BUCHANAN@SUMEX-AIM.Stanford.EDU>
Subject: Departure
To: faculty@score.Stanford.EDU
cc: bscott@score.Stanford.EDU, hemenway@score.Stanford.EDU,
tajnai@score.Stanford.EDU
Message-ID: <12382537722.12.BUCHANAN@SUMEX-AIM.Stanford.EDU>
Friends,
As many of you have heard, I will be leaving Stanford at the end of Spring
Quarter to go to the University of Pittsburgh. Two-career planning is the
primary cause of moving out of the Bay Area: Pitt is one of just a few places
serious about library conservation and AI.
I have enjoyed working with Stanford students immensely and have a great
respect for Stanford staff who keep things running in spite of the faculty.
Working with the MSAI and MIS programs has been very rewarding;
the KSL has been a fantastic source of ideas and energy, and especially of
friendships. I am reluctant to give all that up.
After 22 years at Stanford, however, there is little I can do here that hasn't
been categorized ahead of time. It is time for a different environment, so I
have signed on as Professor of Computer Science, Philosophy, and Medicine at
Pitt.
I'll stll be in touch by electronic mail (BUCHANAN @ SUMEX-AIM will be
forwarded). I'll also be back occasionally, unless, of course, there is truth
to the Stanford claim that one cannot survive farther east than Berkeley, max.
Best regards,
Bruce
-------
∂16-Mar-88 1346 VARDI%ALMVMA.BITNET@forsythe.stanford.edu EDS'88 (Please Distribute)
Received: from navajo.stanford.edu by SAIL.Stanford.EDU with TCP; 16 Mar 88 13:12:34 PST
Received: from Lindy.Stanford.EDU by navajo.stanford.edu with TCP; Wed, 16 Mar 88 11:00:18 PST
Received: by lindy.stanford.edu; Wed, 16 Mar 88 07:07:04 PST
From: VARDI%ALMVMA.BITNET@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Wed, 16 Mar 88 10:46:45 PST
Date: 16 Mar 88 10:46 PST
To: NAIL@navajo.stanford.edu
Subject: EDS'88 (Please Distribute)
Date: 16 March 1988, 10:46:28 PST
From: Moshe Vardi VARDI at ALMVMA
To: NAIL at NAVAJO.STANFORD.EDU
Subject: EDS'88 (Please Distribute)
ADVANCE PROGRAM
The Second International Conference on
Expert Database Systems
April 25-27, 1988
Sheraton Premiere at Tysons Corner, Virginia
Sponsored by: George Mason University
In Cooperation With: American Association for Artificial Intelligence
Association for Computing Machinery - SIGART and SIGMOD
IEEE Computer Society - T. C. on Data Engineering
Conference Objectives
---------------------
The International Conference on Expert Database Systems has
established itself as a leading edge forum that explores the
theoretical and practical issues in making database systems more
intelligent and supportive of Artificial Intelligence (AI)
applications. Expert Database Systems represent the confluence of R&D
activities in Artificial Intelligence, Database Management, Logic and
Logic Programming, Information Retrieval, and Fuzzy Systems Theory.
It is precisely this synergism among disciplines which makes the
Conference both stimulating and unique.
Organizing Committee
--------------------
Conference Chairman
Edgar H. Sibley, George Mason University
Program Chairman
Larry Kerschberg, George Mason University
Program Committee
-----------------
Robert Abarbanel, IntelliCorp
Hideo Aiso, Keio University
Antonio Albano, Univ. di Pisa
Stephen Andriole, GMU
Robert Balzer, USC/ISI
Francois Bancilhon, GIP Altair, France
Don Batory, Univ. of Texas
Alex Borgida, Rutgers University
Michael Brodie, GTE Labs, Inc.
Janis Bubenko, Univ. of Stockholm
Peter Buneman, Univ. of Pennsylvania
Stefano Ceri, Politecnico di Milano
Umesh Dayal, Computer Corp. of America
Mark Fox, Carnegie-Mellon University
Antonio L. Furtado, IBM do Brasil
Herve Gallaire, ECRC, FRG
Barbara Hayes-Roth, Stanford University
Yannis Ioannidis, Univ. of Wisconsin
Sushil Jajodia, National Science Foundation
Matthias Jarke, Univ. of Passau
Jonathan King, Teknowledge, Inc.
Roger King, Univ. of Colorado
Robert Meersman, Tilburg University
Tim Merrett, McGill University
Matthew Morgenstern, SRI International
John Mylopoulos, Univ. of Toronto
Sham Navathe, Univ. of Florida
Erich Neuhold, GMD, FRG
Setuo Ohsuga, Univ. of Tokyo
Stott Parker, UCLA
Alain Pirotte, Philips Research Lab
Don Potter, Univ. of Georgia
Larry Reeker, BDM Corporation
Nick Roussopoulos, Univ. of Maryland
Erik Sandewall, Linkoping University
Timos Sellis, Univ. of Maryland
John Smith, Kendall Square Research
Reid Smith, Schlumberger Palo Alto Res.
Arne Solvberg, Univ. Trondeim
John Sowa, IBM SRI
Jacob Stein, Servio Logic Dev. Corp.
Michael Stonebraker, UC - Berkeley
Adrian Walker, IBM TJ Watson Center
Andrew Whinston, Purdue University
Gio Wiederhold, Stanford University
Eugene Wong, UC - Berkeley
Carlo Zaniolo, MCC
Tutorial and Panel Coordinator
Lucian Russell, Computer Sciences Corp.
Conference Coordinators
Juliette Gregory and Barbara Framer, GMU
Exhibit Coordinators
Diane Tosh Entner, RAMCOR, REassociates
Carolyn Komada, E-Systems, Melpar
Publicity Chairman
Jorge Diaz-Herrera, GMU
Conference Organization and Fee Structure
-----------------------------------------
The three day EDS Conference is organized into the Technical Program
and a concurrent Tutorial Program. There are separate fees for each,
and a special Conference/Tutorial Package fee is also available.
The Conference Fee includes the Technical Program consisting of the
Keynote Address, Paper Sessions with twenty-seven high-quality papers,
three Panels, Proceedings, Exhibits and Vendor Presentations, three
Luncheons, Coffee Breaks, a Hospitality Hour and our Theme Party,
Campaign Capers. The Spirit of Washington Cruise is an optional
social event. Space is limited for the cruise, and early registration
is required.
The Tutorial Program consists of four half-day tutorials, running
concurrently with the Technical Program. It is designed to provide
participants with the latest concepts, tools and techniques related to
R&D in Expert Database Systems. You may enroll for up to four
tutorials. Each tutorial includes tutorial notes, a coffee break and
a luncheon. Thus, participants may choose to attend only tutorials
without attending the Conference. Tutorial participants may purchase
Social Function tickets separately.
The Conference/Tutorial Package is designed to allow conference
participants to attend tutorials at reduced rates, enabling
participants to concentrate on special interest areas of EDS.
Exhibits and Vendor Presentations
---------------------------------
Leading Artificial Intelligence and Database companies plan to exhibit
a range of hardware and software products.
In addition to the exhibits, special sessions are planned for vendor
product briefings and prototype demonstrations. At this writing, the
following vendor presentations have been confirmed: Introduction to
the Application Expert, Cullinet, USA; The KEE Connection,
IntelliCorp, USA; Copernicus, A Modular Tool for Managing Knowledge
and Data, Teknowledge, Inc., USA; and Relational LISP, MAD Computing, USA.
Also, several well-known publishing companies will offer their latest
titles in the fields of Expert Database Systems, Artificial
Intelligence, Expert Systems and Database Management.
Social Functions
----------------
Campaign Capers: Participate in the Expert Database Systems
Conference Presidential Preference Primary! Caucus with your
conference associates to determine who will win the U.S. Presidential
Election in 1988. Participate in the quintessential Washington
activity as you vote for the candidate of your choice, move to
republican rhythms and democratic dances, and enjoy regional American
cuisine and a cash cocktail bar.
Spirit of Washington Cruise: Sail and celebrate springtime in
Washington! Enjoy dinner and a musical Broadway revue as you cruise
on the Potomac River, past Washington's historic landmarks. Be
spirited away on the Spirit of Washington.
Note: The cruise is an optional event, and space on the Spirit of
Washington is limited, so we recommend that you reserve your place
when sending in your Conference Registration Form.
============================
Conference Technical Program
============================
---------------------
Monday, April 25, 1988
----------------------
8:45-9:00 am Opening Remarks
Chairman: Edgar H. Sibley, George Mason University, USA
9:00-10:00 am Keynote Address
Chairman: Larry Kerschberg, George Mason University, USA
Future Directions in Expert Database Systems
Michael Stonebraker, Univ. of California at Berkeley, USA
10:00-10:30 am Coffee Break
10:30-12:00 am Object-Oriented Systems
Chairman: Jacob Stein, Servio Logic, USA
Abstract Objects in an Object-Oriented Data Model
J. Zhu and D. Maier, Oregon Graduate Center, USA
KIVIEW: An Object-Oriented Browser
A. Motro, Univ. of Southern California, USA, A. D'Atri and L.
Tarantino,
Univ. of Rome, Italy
Towards a Unified View of Design Data and Knowledge Representation
B. Mitschang, Universitat Kaiserslautern, FRG
12:00-1:30 pm Luncheon
1:30- 3:00 pm Constraint Management
Chairmen: Herve Gallaire, ECRC, FRG and Alain Pirotte, Philips Labs, Belgium
Implementing Constraints in a Knowledge-Base
J.A. Wald, Schlumberger-Doll Research, USA
Update-Oriented Database Structures
L. Tucherman and A.L. Furtado, IBM Rio Scientific Center, Brazil
Distribution Design of Integrity Constraints
X. Qian, Stanford University, USA
3:00-3:30 pm Coffee Break
3:30-5:00 pm Panel: Constraint-Based Systems: Knowledge about Data
Chairman: Matthew Morgenstern, SRI International, USA
5:30-6:30 pm Hospitality Hour
7:00-10:00 pm Campaign Capers
-----------------------
Tuesday, April 26, 1988
-----------------------
8:30-10:00 am Expert Database System Architectures
Chairmen: Robert Meersman, Tilburg University, and Sushil Jajodia, NSF
BERMUDA - An Architectural Perspective on Interfacing Prolog to a
Database Machine
Y.E. Ioannidis, J. Chen, M.A. Friedman and M.M. Tsangaris, U. of Wisconsin
A Look at Loosely-Coupled Prolog/Database Systems
B. Napheys and D. Herkimer, Martin Marietta, USA
Combining Top Down and Bottom Up Computation in Knowledge Based Systems
M. Nussbaum, ETH, Switzerland
10:00-10:30 am Coffee Break
10:30-12:00 am Morning Parallel Sessions
IA: Knowledge/Data System Architectures
Chairmen: Roger King, Univ. of Colorado and Robert Abarbanel, IntelliCorp
A Distributed Knowledge Model for Multiple Intelligent Agents
Y.P. Li, Jet Propulsion Laboratory, USA
The Relational Production Language: A Production Language for
Relational Databases
L.M.L. Delcambre and J.N. Etheredge, U. of Southwestern Louisiana, USA
A Transaction Oriented Mechanism to Control Processing in a Knowledge
Base Management System
L. Raschid, Univ. of Maryland, USA
IB: Recursive Query Processing
Chairman: Tim H. Merrett, McGill University
Transitive Closure of Transitively Closed Relations
P. Valduriez and S. Khoshafian, MCC, USA
Transforming Nonlinear Recursion to Linear Recursion
Y.E. Ioannidis, Univ. of Wisconsin and E. Wong, UC-Berkeley, USA
A Compressed Transitive Closure Technique for Efficient Fixed-Point
Query Processing
H.V. Jagadish, AT&T Bell Laboratories, USA
12:00-1:30 pm Luncheon
1:30-3:00 pm Afternoon Parallel Sessions
IIA: Learning and Adaptation in Expert Databases
Chairmen: Alex Borgida, Rutgers University and Don Potter, Univ. of Georgia
An Automatic Improvement Processor for an Information Retrieval System
K.P. Brunner, Merit Technology, Inc. and R.R. Korfhage, Univ. of
Pittsburgh, USA
Supporting Object Flavor Evolution through Learning in an
Object-Oriented Database System
Q. Li and D. McLeod, Univ. of Southern California, USA
Implicit Representation of Extensional Answers
C.D. Shum and R. Muntz, UCLA, USA
IIB: Knowledge Management in Deductive Databases
Chairmen: Sham Navathe, U. of Florida and Francois Bancilhon, GIP Altair
Deep Compilation of Large Rule Bases
T.K. Sellis and N. Roussopoulos, Univ. of Maryland, USA
Handling Knowledge by its Representative
C. Sakama and H. Itoh, ICOT, Japan
Integrity Constraint Checking in Deductive Databases using a Rule/Goal Graph
B. Martens and M. Bruynooghe, Katholieke Universiteit Leuven, Belgium
3:00-3:30 pm Coffee Break
3:30-5:00 pm Panel: Knowledge Distribution and Interoperability
Chairman: Michael Brodie, GTE Labs, USA
6:00-11:00 pm Spirit of Washington Cruise
-------------------------
Wednesday, April 27, 1988
-------------------------
9:00-10:30 am Intelligent Database Interfaces
Chairmen: Erich Neuhold, GMD, FRG and Larry Reeker, BDM Corp.
Musing in an Expert Database
S. Fertig and D. Gelernter, Yale University, USA
Cooperative Answering: A Methodology to Provide Intelligent Access
to Databases
F. Cuppens and R. Demolombe, ONERA-CERT, France
G+: Recursive Queries without Recursion
I.F. Cruz, A.O. Mendelzon and P.T. Wood, Univ. of Toronto, Canada
10:30-11:00 am Coffee Break
11:00-12:30 pm Semantic Query Optimization
Chairman: Matthias Jarke, Univ. of Passau, FRG
Automatic Rule Derivation for Semantic Query Optimization
M.D. Siegel, Boston University, USA
A Metainterpreter to Semantically Optimize Queries in Deductive Databases
J. Lobo and J. Minker, Univ. of Maryland, USA
From QSQ towards QoSaQ: Global Optimization of Recursive Queries
L. Vieille, ECRC, FRG
12:30-2:00 pm Luncheon
2:00-3:30 pm Panel: Knowledge Management
Chairman: Adrian Walker, IBM T.J. Watson Research Center, USA
Panelists: R. Kowalski, Imperial College, London, D. Lenat, MCC,
Austin, E. Soloway, Yale University and M. Stonebraker, UC - Berkeley
=========================
Tutorial Program
=========================
Tutorial I - Monday Afternoon, April 25, 1:30 pm - 5:00 pm
Logic and Databases
Instructor: Dr. Carlo Zaniolo, MCC, Austin, Texas
Dr. Zaniolo heads a group at MCC performing research on deductive
databases and logic programming. He has held positions at Sperry
Research and Bell Laboratories. He is the author of over 40 technical
papers, a member of numerous Program Committees, and edited the
December 1987 Data Engineering special issue on Databases and Logic.
Course Description: There is a growing demand for supporting
knowledge-based applications by means of Knowledge Management Systems;
these will have to combine the inference mechanisms of Logic with the
efficient and secure management of data provided by Database
Management Systems(DBMS). The major topics are: Logic and relational
query languages; Semantics of Horn Clauses; Prolog and DBMSs; Coupling
Prolog with a DBMS; Making Prolog a database language; Integrating
Logic and Database Systems: Sets, Negation and Updates; Choosing an
Execution Model; Compilation: magic sets to support recursive
predicates; Optimization and Safety; Overview of selected R&D
projects.
-------------------------------------------------------------------
Tutorial II - Tuesday Morning, April 26, 8:30 am - 12:00 am
Distributed Problem Solving in Knowledge/Data Environments
Instructor: Prof. Victor Lesser, University of Massachusetts,
Amherst, MA
Dr. Lesser is Professor of Computer and Information Science at UMASS,
where he heads research groups in Distributed Artificial Intelligence
and Intelligent User Interfaces. Prior to joining UMASS in 1977, he
was on the faculty of Carnegie-Mellon University, where he was a
Principal in the development of the HEARSAY Speech Understanding
System and responsible for the system architecture.
Course Description: This tutorial will explore the major concepts and
systems for cooperative knowledge-based problem solving. The major
topics include: Connectionist, Actor and Cooperating ES paradigms;
Conceptual Issues including: examples of distributed search,
interpretation, planning and cooperation, global coherence, dealing
with inconsistency and incompleteness, sharing world views, and design
rules for a cooperating ES; System Architectures for satisficing,
negotiation, tolerance of inconsistency in problem-solving,
organizational structuring, integration of local and network control,
and expectation-driven communication; Discussion of working systems
including Contract Nets, Partial Global Planning, AGORA MACE, ABE,
DPS, and MINDS; and Future Directions.
-----------------------------------------------------------------------
Tutorial III - Tuesday Afternoon, April 26, 1:30 pm - 5:00 pm
Knowledge Representation and Data Semantics
Instructor: Prof. John Mylopoulos, University of Toronto, Canada
Dr. John Mylopoulos is Professor of Computer Science at the University
of Toronto and research fellow of the Canadian Institute for Advanced
Research. His research interests include knowledge representation and
its applications to Databases and Software Engineering. Dr.
Mylopoulos has edited three books on the general topic of AI and
Databases. He received his Ph.D degree from Princeton University.
Course Description: Knowledge Representation including history, basic
paradigms such as semantic nets, logic-based representations,
productions, frames, role of uncertainty, and inference mechanisms,
examples such as KL-ONE and OMEGA; Semantic Data Models including
historical models such as Abrial's Binary Model, Entity/Relationship,
RM/T and SDM, detailed study of ADAPLEX, TAXIS, and GALILEO,
implementation techniques; Comparison of SDMs to Object-Oriented model
such as POSTGRES and GEM as well as Deductive Databases.
------------------------------------------------------------------------
Tutorial IV - Wednesday Morning, April 27, 9:00 am - 12:30 pm
Acquisition of Knowledge from Data
Instructor: Prof. Gio Wiederhold, Stanford University, Stanford,
California
Dr. Gio Wiederhold is Associate Professor of Medicine and Computer
Science (Research) at Stanford University. His research involves
knowledge-based approaches to medicine, design, and planning. He is
the Editor-in-Chief of ACM's Transactions on Database Systems and
associate editor of M.D. Computing and IEEE Expert magazine.
Wiederhold has over 130 publications, including a widely used textbook
on Database Design. In 1987, McGraw-Hill published his new book, File
Organization for Database Design.
Course Description: The architecture of an operational system, RX, is
presented which uses knowledge-based techniques to extract new
knowledge from a large clinical database. RX exploits both
frame-based knowledge and rules, as well as a database. Frames are
used to store deep and interconnected knowledge about disease states
and medical actions. Definitional and causal knowledge is
represented by inter-connections between frames that go across the
hierarchies, sideways as well as up and down, so that the aggregate
knowledge is represented by a network. Rules select the appropriate
statistical methods used to reduce the volume of data into
information. The database contains observations on rheumatic
diseases, collected over a dozen years.
-------------------------------------------------------------------------
Travel Arrangements
-------------------
The official travel agent for EDS'88 is: ALL Travel, Four Seasons One
Building, 3016 Williams Dr., Suite 1, Fairfax, VA 22031, USA. All
Travel's toll-free number is 1-800-338-8137; TELEX No. 910-250-1473
with Answer Back ALLTVL UQ. Please mention the Expert Database
Conference when making reservations. All Travel offers substantial
discounts for EDS'88 participants for International and Domestic
Flights on Pan Am, Delta, and United.
Airports and Ground Transportation
----------------------------------
The EDS'88 Conference Hotel is the Sheraton Premiere, located about 15
miles from the Washington Dulles International Airport. Both domestic
and international flights use Dulles. The Sheraton provides free
shuttle service from Dulles, leaving every hour on the hour, and
picking up passengers on the Arrivals Level between Baggage Areas 1
and 2. The Washington National Airport is convenient for many
Domestic Flights, and taxi service is available.
For those driving, the Sheraton offers free parking, and is located at
8661 Leesburg Pike at Tyson's Corner, about two miles West of the
Beltway (I-495).
Conference and Tutorial Fee Instructions
----------------------------------------
The Conference and Tutorial Fees table below shows the fee structure
for a) Conference only, b) Tutorials only, and c) the
Conference/Tutorial Package. First, decide whether you are going to
attend a), b) or c). If you are attending tutorials, decide how many
and check the appropriate number under b) or c). Finally, on the row
you have checked, circle the appropriate amount based on Early (on or
before March 21) or Late (after March 21) registration, and the
appropriate membership category: Member, Regular, or Student.
The Member rate applies to members of our cooperating societies:
AAAI, ACM or IEEE. The Regular rate applies to non-members of these
societies, and the Student rate applies to students.
Please Fill in the Form below and detach between the "========"
delimiters. Return the Hotel form directly to the Sheraton.
=======================================================================
Conference and Tutorial Fees
----------------------------
--------------------------------------------------------------------
On or Before March 21 | After March 21
--------------------------------------------------------------------
Mem. Reg. Stu. | Mem. Reg. Stu
--------------------------------------------------------------------
a) Conf. only ___ $250 $320 $100 | $300 $370 $150
--------------------------------------------------------------------
b) Tutorials only,
check qty. desired
One ___ $170 $170 $100 | $180 $180 $110
Two ___ $300 $300 $180 | $320 $320 $200
Three ___ $380 $380 $220 | $410 $410 $250
Four ___ $450 $450 $250 | $490 $490 $290
--------------------------------------------------------------------
c) Conf./Tut. Package
check qty. desired
One ___ $370 $440 $200 | $420 $490 $250
Two ___ $450 $520 $280 | $500 $570 $330
Three ___ $510 $580 $320 | $560 $630 $370
Four ___ $550 $620 $350 | $600 $670 $400
--------------------------------------------------------------------
Conference Registration Form
----------------------------
All payments must be in U.S. Dollars. Methods of payment are check,
bank drafts, Visa or Mastercard.
Make checks payable to the: GMU Foundation.
For telephone queries call (703) 323-2198. Send
completed registration form and remittance to:
EDS Conference
Office of Community Services, Div. of Continuing Education
George Mason University
4400 University Drive
Fairfax, VA 22030, USA
Name _________________________________________________
Organization _________________________________________________
Address _________________________________________________
City, State, ZIP _______________________________________________
Country _______________________________________________
Business Phone _________________________________________________
AIII/ACM/IEEE # _________________________________________________
Credit Card: VS or MC (circle one) No___________________________
Expiration Date _______ and
Signature: __________________________________________________
Tutorials selected (if applicable):
___ I: Logic and Databases ___ II: Distributed AI/DB Environments
___ III: K.R. & Data Semantics ___ IV: Acqusition of Knowledge from Data
Additional Social Function tickets may be purchased. Indicate
quantities below:
___ Campaign Capers @ $50
___ Spirit of Washington @ $35 (Note this is an optional event;
register early!).
Total Amount Included _________________________________________
========================================================================
Hotel Reservation Form: Please fill out the form and mail by April 4
to: Sheraton Premiere at Tysons Corner, 8661 Leesburg Pike, Vienna,
VA 22180, USA
######################################################################
Second International Conference on Expert Database Systems
April 24-27, 1988
Special Rates: $90 for Single/Double, $99 Triple
Suite Rates Available Upon Request
PLEASE PRINT
Name ________________________________________________________________
last first
Street _________________________________________________________
City ________________________ State _____________ Zip _________
Arrival Date ______________________________________________________
day of week month date time
Departure Date _____________________________________________________
day of week month date
Please Reserve ____________________ room(s) for ___________ persons(s)
NAMES OF PERSONS SHARING ACCOMMODATIONS
________________________________________________________________________
Rollaway -- $15 extra per night
Reservations must be received at the hotel by APRIL 4, 1988.
Reservations received after this date will be accepted on a space and
rate available basis only.
-------------------
GUARANTEED RESERVATIONS
-------------------
First Night Deposit of Major Credit Card for any arrival after 4 PM.
A guaranteed payment assures you that a room will be held for your day
of arrival. The room will become available for resale if you have not
registered by 6:00 AM THE FOLLOWING MORNING. You will be billed for
the first night's room & tax revenue if the reservation is not
cancelled before 6PM (EST) on the day of arrival. Please ask the
clerk for a cancellation number (703/448-1234).
GUARANTEE INFORMATION: (Please Print).
Firm Name ________________________________________________
Address __________________________________________________
City ________________________ State _____________ Zip _________
Home Phone ____________________ Business Phone ____________________
Credit Card ____________________________________________________
AX, VISA, MC, DC, CB (circle one)
Expiration Date: _________________________
Signature: _____________________________________________________
CHECK OUT TIME IS 12 Noon; ROOMS WILL NOT BE READY FOR YOUR ARRIVAL
UNTIL 3 PM.
#####################################################################
∂16-Mar-88 1346 TAJNAI@Score.Stanford.EDU IBM Fellowship Nominees
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 88 13:12:22 PST
Date: Tue 15 Mar 88 08:22:05-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: IBM Fellowship Nominees
To: faculty@Score.Stanford.EDU
Message-ID: <12382550623.28.TAJNAI@Score.Stanford.EDU>
The department is nominating Tom Henzinger and Karen Myers for the
IBM Fellowship.
Carolyn
-------
∂16-Mar-88 1312 VARDI%ALMVMA.BITNET@forsythe.stanford.edu EDS'88 (Please Distribute)
Received: from navajo.stanford.edu by SAIL.Stanford.EDU with TCP; 16 Mar 88 13:12:34 PST
Received: from Lindy.Stanford.EDU by navajo.stanford.edu with TCP; Wed, 16 Mar 88 11:00:18 PST
Received: by lindy.stanford.edu; Wed, 16 Mar 88 07:07:04 PST
From: VARDI%ALMVMA.BITNET@forsythe.stanford.edu
Received: by Forsythe.Stanford.EDU; Wed, 16 Mar 88 10:46:45 PST
Date: 16 Mar 88 10:46 PST
To: NAIL@navajo.stanford.edu
Subject: EDS'88 (Please Distribute)
Date: 16 March 1988, 10:46:28 PST
From: Moshe Vardi VARDI at ALMVMA
To: NAIL at NAVAJO.STANFORD.EDU
Subject: EDS'88 (Please Distribute)
ADVANCE PROGRAM
The Second International Conference on
Expert Database Systems
April 25-27, 1988
Sheraton Premiere at Tysons Corner, Virginia
Sponsored by: George Mason University
In Cooperation With: American Association for Artificial Intelligence
Association for Computing Machinery - SIGART and SIGMOD
IEEE Computer Society - T. C. on Data Engineering
Conference Objectives
---------------------
The International Conference on Expert Database Systems has
established itself as a leading edge forum that explores the
theoretical and practical issues in making database systems more
intelligent and supportive of Artificial Intelligence (AI)
applications. Expert Database Systems represent the confluence of R&D
activities in Artificial Intelligence, Database Management, Logic and
Logic Programming, Information Retrieval, and Fuzzy Systems Theory.
It is precisely this synergism among disciplines which makes the
Conference both stimulating and unique.
Organizing Committee
--------------------
Conference Chairman
Edgar H. Sibley, George Mason University
Program Chairman
Larry Kerschberg, George Mason University
Program Committee
-----------------
Robert Abarbanel, IntelliCorp
Hideo Aiso, Keio University
Antonio Albano, Univ. di Pisa
Stephen Andriole, GMU
Robert Balzer, USC/ISI
Francois Bancilhon, GIP Altair, France
Don Batory, Univ. of Texas
Alex Borgida, Rutgers University
Michael Brodie, GTE Labs, Inc.
Janis Bubenko, Univ. of Stockholm
Peter Buneman, Univ. of Pennsylvania
Stefano Ceri, Politecnico di Milano
Umesh Dayal, Computer Corp. of America
Mark Fox, Carnegie-Mellon University
Antonio L. Furtado, IBM do Brasil
Herve Gallaire, ECRC, FRG
Barbara Hayes-Roth, Stanford University
Yannis Ioannidis, Univ. of Wisconsin
Sushil Jajodia, National Science Foundation
Matthias Jarke, Univ. of Passau
Jonathan King, Teknowledge, Inc.
Roger King, Univ. of Colorado
Robert Meersman, Tilburg University
Tim Merrett, McGill University
Matthew Morgenstern, SRI International
John Mylopoulos, Univ. of Toronto
Sham Navathe, Univ. of Florida
Erich Neuhold, GMD, FRG
Setuo Ohsuga, Univ. of Tokyo
Stott Parker, UCLA
Alain Pirotte, Philips Research Lab
Don Potter, Univ. of Georgia
Larry Reeker, BDM Corporation
Nick Roussopoulos, Univ. of Maryland
Erik Sandewall, Linkoping University
Timos Sellis, Univ. of Maryland
John Smith, Kendall Square Research
Reid Smith, Schlumberger Palo Alto Res.
Arne Solvberg, Univ. Trondeim
John Sowa, IBM SRI
Jacob Stein, Servio Logic Dev. Corp.
Michael Stonebraker, UC - Berkeley
Adrian Walker, IBM TJ Watson Center
Andrew Whinston, Purdue University
Gio Wiederhold, Stanford University
Eugene Wong, UC - Berkeley
Carlo Zaniolo, MCC
Tutorial and Panel Coordinator
Lucian Russell, Computer Sciences Corp.
Conference Coordinators
Juliette Gregory and Barbara Framer, GMU
Exhibit Coordinators
Diane Tosh Entner, RAMCOR, REassociates
Carolyn Komada, E-Systems, Melpar
Publicity Chairman
Jorge Diaz-Herrera, GMU
Conference Organization and Fee Structure
-----------------------------------------
The three day EDS Conference is organized into the Technical Program
and a concurrent Tutorial Program. There are separate fees for each,
and a special Conference/Tutorial Package fee is also available.
The Conference Fee includes the Technical Program consisting of the
Keynote Address, Paper Sessions with twenty-seven high-quality papers,
three Panels, Proceedings, Exhibits and Vendor Presentations, three
Luncheons, Coffee Breaks, a Hospitality Hour and our Theme Party,
Campaign Capers. The Spirit of Washington Cruise is an optional
social event. Space is limited for the cruise, and early registration
is required.
The Tutorial Program consists of four half-day tutorials, running
concurrently with the Technical Program. It is designed to provide
participants with the latest concepts, tools and techniques related to
R&D in Expert Database Systems. You may enroll for up to four
tutorials. Each tutorial includes tutorial notes, a coffee break and
a luncheon. Thus, participants may choose to attend only tutorials
without attending the Conference. Tutorial participants may purchase
Social Function tickets separately.
The Conference/Tutorial Package is designed to allow conference
participants to attend tutorials at reduced rates, enabling
participants to concentrate on special interest areas of EDS.
Exhibits and Vendor Presentations
---------------------------------
Leading Artificial Intelligence and Database companies plan to exhibit
a range of hardware and software products.
In addition to the exhibits, special sessions are planned for vendor
product briefings and prototype demonstrations. At this writing, the
following vendor presentations have been confirmed: Introduction to
the Application Expert, Cullinet, USA; The KEE Connection,
IntelliCorp, USA; Copernicus, A Modular Tool for Managing Knowledge
and Data, Teknowledge, Inc., USA; and Relational LISP, MAD Computing, USA.
Also, several well-known publishing companies will offer their latest
titles in the fields of Expert Database Systems, Artificial
Intelligence, Expert Systems and Database Management.
Social Functions
----------------
Campaign Capers: Participate in the Expert Database Systems
Conference Presidential Preference Primary! Caucus with your
conference associates to determine who will win the U.S. Presidential
Election in 1988. Participate in the quintessential Washington
activity as you vote for the candidate of your choice, move to
republican rhythms and democratic dances, and enjoy regional American
cuisine and a cash cocktail bar.
Spirit of Washington Cruise: Sail and celebrate springtime in
Washington! Enjoy dinner and a musical Broadway revue as you cruise
on the Potomac River, past Washington's historic landmarks. Be
spirited away on the Spirit of Washington.
Note: The cruise is an optional event, and space on the Spirit of
Washington is limited, so we recommend that you reserve your place
when sending in your Conference Registration Form.
============================
Conference Technical Program
============================
---------------------
Monday, April 25, 1988
----------------------
8:45-9:00 am Opening Remarks
Chairman: Edgar H. Sibley, George Mason University, USA
9:00-10:00 am Keynote Address
Chairman: Larry Kerschberg, George Mason University, USA
Future Directions in Expert Database Systems
Michael Stonebraker, Univ. of California at Berkeley, USA
10:00-10:30 am Coffee Break
10:30-12:00 am Object-Oriented Systems
Chairman: Jacob Stein, Servio Logic, USA
Abstract Objects in an Object-Oriented Data Model
J. Zhu and D. Maier, Oregon Graduate Center, USA
KIVIEW: An Object-Oriented Browser
A. Motro, Univ. of Southern California, USA, A. D'Atri and L.
Tarantino,
Univ. of Rome, Italy
Towards a Unified View of Design Data and Knowledge Representation
B. Mitschang, Universitat Kaiserslautern, FRG
12:00-1:30 pm Luncheon
1:30- 3:00 pm Constraint Management
Chairmen: Herve Gallaire, ECRC, FRG and Alain Pirotte, Philips Labs, Belgium
Implementing Constraints in a Knowledge-Base
J.A. Wald, Schlumberger-Doll Research, USA
Update-Oriented Database Structures
L. Tucherman and A.L. Furtado, IBM Rio Scientific Center, Brazil
Distribution Design of Integrity Constraints
X. Qian, Stanford University, USA
3:00-3:30 pm Coffee Break
3:30-5:00 pm Panel: Constraint-Based Systems: Knowledge about Data
Chairman: Matthew Morgenstern, SRI International, USA
5:30-6:30 pm Hospitality Hour
7:00-10:00 pm Campaign Capers
-----------------------
Tuesday, April 26, 1988
-----------------------
8:30-10:00 am Expert Database System Architectures
Chairmen: Robert Meersman, Tilburg University, and Sushil Jajodia, NSF
BERMUDA - An Architectural Perspective on Interfacing Prolog to a
Database Machine
Y.E. Ioannidis, J. Chen, M.A. Friedman and M.M. Tsangaris, U. of Wisconsin
A Look at Loosely-Coupled Prolog/Database Systems
B. Napheys and D. Herkimer, Martin Marietta, USA
Combining Top Down and Bottom Up Computation in Knowledge Based Systems
M. Nussbaum, ETH, Switzerland
10:00-10:30 am Coffee Break
10:30-12:00 am Morning Parallel Sessions
IA: Knowledge/Data System Architectures
Chairmen: Roger King, Univ. of Colorado and Robert Abarbanel, IntelliCorp
A Distributed Knowledge Model for Multiple Intelligent Agents
Y.P. Li, Jet Propulsion Laboratory, USA
The Relational Production Language: A Production Language for
Relational Databases
L.M.L. Delcambre and J.N. Etheredge, U. of Southwestern Louisiana, USA
A Transaction Oriented Mechanism to Control Processing in a Knowledge
Base Management System
L. Raschid, Univ. of Maryland, USA
IB: Recursive Query Processing
Chairman: Tim H. Merrett, McGill University
Transitive Closure of Transitively Closed Relations
P. Valduriez and S. Khoshafian, MCC, USA
Transforming Nonlinear Recursion to Linear Recursion
Y.E. Ioannidis, Univ. of Wisconsin and E. Wong, UC-Berkeley, USA
A Compressed Transitive Closure Technique for Efficient Fixed-Point
Query Processing
H.V. Jagadish, AT&T Bell Laboratories, USA
12:00-1:30 pm Luncheon
1:30-3:00 pm Afternoon Parallel Sessions
IIA: Learning and Adaptation in Expert Databases
Chairmen: Alex Borgida, Rutgers University and Don Potter, Univ. of Georgia
An Automatic Improvement Processor for an Information Retrieval System
K.P. Brunner, Merit Technology, Inc. and R.R. Korfhage, Univ. of
Pittsburgh, USA
Supporting Object Flavor Evolution through Learning in an
Object-Oriented Database System
Q. Li and D. McLeod, Univ. of Southern California, USA
Implicit Representation of Extensional Answers
C.D. Shum and R. Muntz, UCLA, USA
IIB: Knowledge Management in Deductive Databases
Chairmen: Sham Navathe, U. of Florida and Francois Bancilhon, GIP Altair
Deep Compilation of Large Rule Bases
T.K. Sellis and N. Roussopoulos, Univ. of Maryland, USA
Handling Knowledge by its Representative
C. Sakama and H. Itoh, ICOT, Japan
Integrity Constraint Checking in Deductive Databases using a Rule/Goal Graph
B. Martens and M. Bruynooghe, Katholieke Universiteit Leuven, Belgium
3:00-3:30 pm Coffee Break
3:30-5:00 pm Panel: Knowledge Distribution and Interoperability
Chairman: Michael Brodie, GTE Labs, USA
6:00-11:00 pm Spirit of Washington Cruise
-------------------------
Wednesday, April 27, 1988
-------------------------
9:00-10:30 am Intelligent Database Interfaces
Chairmen: Erich Neuhold, GMD, FRG and Larry Reeker, BDM Corp.
Musing in an Expert Database
S. Fertig and D. Gelernter, Yale University, USA
Cooperative Answering: A Methodology to Provide Intelligent Access
to Databases
F. Cuppens and R. Demolombe, ONERA-CERT, France
G+: Recursive Queries without Recursion
I.F. Cruz, A.O. Mendelzon and P.T. Wood, Univ. of Toronto, Canada
10:30-11:00 am Coffee Break
11:00-12:30 pm Semantic Query Optimization
Chairman: Matthias Jarke, Univ. of Passau, FRG
Automatic Rule Derivation for Semantic Query Optimization
M.D. Siegel, Boston University, USA
A Metainterpreter to Semantically Optimize Queries in Deductive Databases
J. Lobo and J. Minker, Univ. of Maryland, USA
From QSQ towards QoSaQ: Global Optimization of Recursive Queries
L. Vieille, ECRC, FRG
12:30-2:00 pm Luncheon
2:00-3:30 pm Panel: Knowledge Management
Chairman: Adrian Walker, IBM T.J. Watson Research Center, USA
Panelists: R. Kowalski, Imperial College, London, D. Lenat, MCC,
Austin, E. Soloway, Yale University and M. Stonebraker, UC - Berkeley
=========================
Tutorial Program
=========================
Tutorial I - Monday Afternoon, April 25, 1:30 pm - 5:00 pm
Logic and Databases
Instructor: Dr. Carlo Zaniolo, MCC, Austin, Texas
Dr. Zaniolo heads a group at MCC performing research on deductive
databases and logic programming. He has held positions at Sperry
Research and Bell Laboratories. He is the author of over 40 technical
papers, a member of numerous Program Committees, and edited the
December 1987 Data Engineering special issue on Databases and Logic.
Course Description: There is a growing demand for supporting
knowledge-based applications by means of Knowledge Management Systems;
these will have to combine the inference mechanisms of Logic with the
efficient and secure management of data provided by Database
Management Systems(DBMS). The major topics are: Logic and relational
query languages; Semantics of Horn Clauses; Prolog and DBMSs; Coupling
Prolog with a DBMS; Making Prolog a database language; Integrating
Logic and Database Systems: Sets, Negation and Updates; Choosing an
Execution Model; Compilation: magic sets to support recursive
predicates; Optimization and Safety; Overview of selected R&D
projects.
-------------------------------------------------------------------
Tutorial II - Tuesday Morning, April 26, 8:30 am - 12:00 am
Distributed Problem Solving in Knowledge/Data Environments
Instructor: Prof. Victor Lesser, University of Massachusetts,
Amherst, MA
Dr. Lesser is Professor of Computer and Information Science at UMASS,
where he heads research groups in Distributed Artificial Intelligence
and Intelligent User Interfaces. Prior to joining UMASS in 1977, he
was on the faculty of Carnegie-Mellon University, where he was a
Principal in the development of the HEARSAY Speech Understanding
System and responsible for the system architecture.
Course Description: This tutorial will explore the major concepts and
systems for cooperative knowledge-based problem solving. The major
topics include: Connectionist, Actor and Cooperating ES paradigms;
Conceptual Issues including: examples of distributed search,
interpretation, planning and cooperation, global coherence, dealing
with inconsistency and incompleteness, sharing world views, and design
rules for a cooperating ES; System Architectures for satisficing,
negotiation, tolerance of inconsistency in problem-solving,
organizational structuring, integration of local and network control,
and expectation-driven communication; Discussion of working systems
including Contract Nets, Partial Global Planning, AGORA MACE, ABE,
DPS, and MINDS; and Future Directions.
-----------------------------------------------------------------------
Tutorial III - Tuesday Afternoon, April 26, 1:30 pm - 5:00 pm
Knowledge Representation and Data Semantics
Instructor: Prof. John Mylopoulos, University of Toronto, Canada
Dr. John Mylopoulos is Professor of Computer Science at the University
of Toronto and research fellow of the Canadian Institute for Advanced
Research. His research interests include knowledge representation and
its applications to Databases and Software Engineering. Dr.
Mylopoulos has edited three books on the general topic of AI and
Databases. He received his Ph.D degree from Princeton University.
Course Description: Knowledge Representation including history, basic
paradigms such as semantic nets, logic-based representations,
productions, frames, role of uncertainty, and inference mechanisms,
examples such as KL-ONE and OMEGA; Semantic Data Models including
historical models such as Abrial's Binary Model, Entity/Relationship,
RM/T and SDM, detailed study of ADAPLEX, TAXIS, and GALILEO,
implementation techniques; Comparison of SDMs to Object-Oriented model
such as POSTGRES and GEM as well as Deductive Databases.
------------------------------------------------------------------------
Tutorial IV - Wednesday Morning, April 27, 9:00 am - 12:30 pm
Acquisition of Knowledge from Data
Instructor: Prof. Gio Wiederhold, Stanford University, Stanford,
California
Dr. Gio Wiederhold is Associate Professor of Medicine and Computer
Science (Research) at Stanford University. His research involves
knowledge-based approaches to medicine, design, and planning. He is
the Editor-in-Chief of ACM's Transactions on Database Systems and
associate editor of M.D. Computing and IEEE Expert magazine.
Wiederhold has over 130 publications, including a widely used textbook
on Database Design. In 1987, McGraw-Hill published his new book, File
Organization for Database Design.
Course Description: The architecture of an operational system, RX, is
presented which uses knowledge-based techniques to extract new
knowledge from a large clinical database. RX exploits both
frame-based knowledge and rules, as well as a database. Frames are
used to store deep and interconnected knowledge about disease states
and medical actions. Definitional and causal knowledge is
represented by inter-connections between frames that go across the
hierarchies, sideways as well as up and down, so that the aggregate
knowledge is represented by a network. Rules select the appropriate
statistical methods used to reduce the volume of data into
information. The database contains observations on rheumatic
diseases, collected over a dozen years.
-------------------------------------------------------------------------
Travel Arrangements
-------------------
The official travel agent for EDS'88 is: ALL Travel, Four Seasons One
Building, 3016 Williams Dr., Suite 1, Fairfax, VA 22031, USA. All
Travel's toll-free number is 1-800-338-8137; TELEX No. 910-250-1473
with Answer Back ALLTVL UQ. Please mention the Expert Database
Conference when making reservations. All Travel offers substantial
discounts for EDS'88 participants for International and Domestic
Flights on Pan Am, Delta, and United.
Airports and Ground Transportation
----------------------------------
The EDS'88 Conference Hotel is the Sheraton Premiere, located about 15
miles from the Washington Dulles International Airport. Both domestic
and international flights use Dulles. The Sheraton provides free
shuttle service from Dulles, leaving every hour on the hour, and
picking up passengers on the Arrivals Level between Baggage Areas 1
and 2. The Washington National Airport is convenient for many
Domestic Flights, and taxi service is available.
For those driving, the Sheraton offers free parking, and is located at
8661 Leesburg Pike at Tyson's Corner, about two miles West of the
Beltway (I-495).
Conference and Tutorial Fee Instructions
----------------------------------------
The Conference and Tutorial Fees table below shows the fee structure
for a) Conference only, b) Tutorials only, and c) the
Conference/Tutorial Package. First, decide whether you are going to
attend a), b) or c). If you are attending tutorials, decide how many
and check the appropriate number under b) or c). Finally, on the row
you have checked, circle the appropriate amount based on Early (on or
before March 21) or Late (after March 21) registration, and the
appropriate membership category: Member, Regular, or Student.
The Member rate applies to members of our cooperating societies:
AAAI, ACM or IEEE. The Regular rate applies to non-members of these
societies, and the Student rate applies to students.
Please Fill in the Form below and detach between the "========"
delimiters. Return the Hotel form directly to the Sheraton.
=======================================================================
Conference and Tutorial Fees
----------------------------
--------------------------------------------------------------------
On or Before March 21 | After March 21
--------------------------------------------------------------------
Mem. Reg. Stu. | Mem. Reg. Stu
--------------------------------------------------------------------
a) Conf. only ___ $250 $320 $100 | $300 $370 $150
--------------------------------------------------------------------
b) Tutorials only,
check qty. desired
One ___ $170 $170 $100 | $180 $180 $110
Two ___ $300 $300 $180 | $320 $320 $200
Three ___ $380 $380 $220 | $410 $410 $250
Four ___ $450 $450 $250 | $490 $490 $290
--------------------------------------------------------------------
c) Conf./Tut. Package
check qty. desired
One ___ $370 $440 $200 | $420 $490 $250
Two ___ $450 $520 $280 | $500 $570 $330
Three ___ $510 $580 $320 | $560 $630 $370
Four ___ $550 $620 $350 | $600 $670 $400
--------------------------------------------------------------------
Conference Registration Form
----------------------------
All payments must be in U.S. Dollars. Methods of payment are check,
bank drafts, Visa or Mastercard.
Make checks payable to the: GMU Foundation.
For telephone queries call (703) 323-2198. Send
completed registration form and remittance to:
EDS Conference
Office of Community Services, Div. of Continuing Education
George Mason University
4400 University Drive
Fairfax, VA 22030, USA
Name _________________________________________________
Organization _________________________________________________
Address _________________________________________________
City, State, ZIP _______________________________________________
Country _______________________________________________
Business Phone _________________________________________________
AIII/ACM/IEEE # _________________________________________________
Credit Card: VS or MC (circle one) No___________________________
Expiration Date _______ and
Signature: __________________________________________________
Tutorials selected (if applicable):
___ I: Logic and Databases ___ II: Distributed AI/DB Environments
___ III: K.R. & Data Semantics ___ IV: Acqusition of Knowledge from Data
Additional Social Function tickets may be purchased. Indicate
quantities below:
___ Campaign Capers @ $50
___ Spirit of Washington @ $35 (Note this is an optional event;
register early!).
Total Amount Included _________________________________________
========================================================================
Hotel Reservation Form: Please fill out the form and mail by April 4
to: Sheraton Premiere at Tysons Corner, 8661 Leesburg Pike, Vienna,
VA 22180, USA
######################################################################
Second International Conference on Expert Database Systems
April 24-27, 1988
Special Rates: $90 for Single/Double, $99 Triple
Suite Rates Available Upon Request
PLEASE PRINT
Name ________________________________________________________________
last first
Street _________________________________________________________
City ________________________ State _____________ Zip _________
Arrival Date ______________________________________________________
day of week month date time
Departure Date _____________________________________________________
day of week month date
Please Reserve ____________________ room(s) for ___________ persons(s)
NAMES OF PERSONS SHARING ACCOMMODATIONS
________________________________________________________________________
Rollaway -- $15 extra per night
Reservations must be received at the hotel by APRIL 4, 1988.
Reservations received after this date will be accepted on a space and
rate available basis only.
-------------------
GUARANTEED RESERVATIONS
-------------------
First Night Deposit of Major Credit Card for any arrival after 4 PM.
A guaranteed payment assures you that a room will be held for your day
of arrival. The room will become available for resale if you have not
registered by 6:00 AM THE FOLLOWING MORNING. You will be billed for
the first night's room & tax revenue if the reservation is not
cancelled before 6PM (EST) on the day of arrival. Please ask the
clerk for a cancellation number (703/448-1234).
GUARANTEE INFORMATION: (Please Print).
Firm Name ________________________________________________
Address __________________________________________________
City ________________________ State _____________ Zip _________
Home Phone ____________________ Business Phone ____________________
Credit Card ____________________________________________________
AX, VISA, MC, DC, CB (circle one)
Expiration Date: _________________________
Signature: _____________________________________________________
CHECK OUT TIME IS 12 Noon; ROOMS WILL NOT BE READY FOR YOUR ARRIVAL
UNTIL 3 PM.
#####################################################################
∂16-Mar-88 1736 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Faculty Salaries
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 88 17:30:57 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 16 Mar 88 17:26:26-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA15803; Wed, 16 Mar 88 17:30:14 PST
Date: Wed, 16 Mar 88 17:30:14 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8803170130.AA15803@Tenaya.stanford.edu>
To: ac@score
Subject: Faculty Salaries
To CS faculty only:
It's time for me to start preparing material for my annual discussion
with the deans about faculty salaries and raises. I have the "faculty
reports" that you submitted to the Dean's Office last December and I
have my own mixture of partly objective, partly subjective impressions to
guide me in this process. I encourage anyone who thinks that his
faculty report might benefit by supplementary material to let me have
such within the next ten days or so. I'd also be glad to talk to anyone
about his role at Stanford, past and future---although I'll be away during
the between-quarter break.
The process of turning facts and impressions into a number is
difficult, but that is exactly what must be done in the raise-setting
process. This year the Dean's office is implementing throughout the
School a process I have been using (with a grain of salt) for the last
couple of years. I try to analyze how everyone in the Department
ranks on five scales, namely Research, PhD Student Involvement, Teaching,
Service, and "Recognition." Then I weight these (roughly 25%,
15%, 25%, 15%, 20%, respectively) to obtain a merit ranking within the
Department. Obviously the weighting shouldn't be the same for everyone;
junior faculty aren't expected to rank as high on recognition (i.e., fame),
nor should they be expected to spend a lot of their time on service;
research faculty aren't expected to teach.
It would be helpful and interesting to hear from as many of you as
would like to respond (hard copy private to me) how you feel you rank
in the Department on these scales. Include any explanatory notes that
you think would be useful. I don't think I need indivualized opinions
about the weighting factors.
Just to prime the pump, here's how I would rank myself (but you
don't have to let everyone know your self-rankings as I am doing now).
Scale Percentile* Comments
(99 is tops)
Research: 25 Not enough time, but I'm doing some.
PhD Students: 75 I have a lot of them, but I probably
don't spend enough time with them.
Teaching: 50 I do one course reasonably well.
Service: 99 Anyone want to quibble about this?
Recognition: 75 There are a lot of famous people around here.
* Note: Percentile refers to your standing in the Stanford
Computer Science Department, not in the world!
Any facts not available in your faculty report that would help me
believe your self-ranking would be very useful.
-Nils
∂16-Mar-88 1736 @Score.Stanford.EDU:MYERS@Sushi.Stanford.EDU Computer Folklore Book
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 88 17:30:45 PST
Received: from Sushi.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 15 Mar 88 11:52:06-PST
Date: Tue 15 Mar 88 11:51:54-PST
From: Karen L. Myers <MYERS@Sushi.Stanford.EDU>
Subject: Computer Folklore Book
To: students@Score.Stanford.EDU, faculty@Score.Stanford.EDU
Message-ID: <12382588819.40.MYERS@Sushi.Stanford.EDU>
Karla Jennings, a reporter from NOrth Carolina, is visiting
Stanford today to interview students for a book she's writing on
computer folklore. She's interested in swapping coffee and pastries
at the Coffee House for tales. She'll be in the lounge at 4 to meet
people, and will head over to the Coffee House around 5:30. Her treat!
The Bureaucrats
-------
∂16-Mar-88 1736 @Score.Stanford.EDU:wheaton@athena.stanford.edu Retreat
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 88 17:31:05 PST
Received: from athena.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 15 Mar 88 11:55:07-PST
Received: by athena.stanford.edu (4.0/SMI-DDN)
id AA05098; Tue, 15 Mar 88 11:59:33 PST
Date: Tue, 15 Mar 88 11:59:33 PST
From: wheaton@athena.stanford.edu (George Wheaton)
Message-Id: <8803151959.AA05098@athena.stanford.edu>
To: ac@score
Subject: Retreat
Various Visiting and Consulting Faculty have expressed interest in
attending the retreat. In the interest of keeping it small,
Consulting Faculty probably should not be included. The real question
is: should Visiting Faculty, such as Arthur Keller, be invited? Let
me know, and I'll invite or not invite, as you think appropriate.
George
∂17-Mar-88 1533 hilbert@russell.stanford.edu Spring faculty meeting
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 17 Mar 88 15:33:34 PST
Received: from russell.stanford.edu by csli.stanford.edu (3.2/4.7); Thu, 17 Mar 88 15:36:21 PST
Received: from localhost by russell.stanford.edu (3.2/4.7); Thu, 17 Mar 88 15:37:52 PST
To: ssp-faculty@russell.stanford.edu
Subject: Spring faculty meeting
Date: Thu, 17 Mar 88 15:37:50 PST
From: David Hilbert <hilbert@russell.stanford.edu>
We will be having an SSP faculty meeting April 26. As is usual the
meeting will be for lunch at the faculty club. An agenda and
reminders will follow later.
Dave Hilbert (Hilbert@csli)
∂17-Mar-88 1601 CHANDLER@Score.Stanford.EDU
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 88 16:01:05 PST
Date: Thu 17 Mar 88 15:57:02-PST
From: Joyce R. Chandler <CHANDLER@Score.Stanford.EDU>
To: jmc-lists@Sail.Stanford.EDU
Message-ID: <12383157733.23.CHANDLER@Score.Stanford.EDU>
Trying to put a name with an address...who are you?
-------
∂17-Mar-88 1700 nilsson@Tenaya.stanford.edu Spring faculty meeting
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 17 Mar 88 17:00:18 PST
Received: from russell.stanford.edu by csli.stanford.edu (3.2/4.7); Thu, 17 Mar 88 17:02:52 PST
Received: from Tenaya.stanford.edu by russell.stanford.edu (3.2/4.7); Thu, 17 Mar 88 17:04:20 PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA16715; Thu, 17 Mar 88 16:59:17 PST
Date: Thu, 17 Mar 88 16:59:17 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8803180059.AA16715@Tenaya.stanford.edu>
To: hilbert@russell.stanford.edu
Cc: ssp-faculty@russell.stanford.edu
In-Reply-To: David Hilbert's message of Thu, 17 Mar 88 15:37:50 PST <8803172333.AA16620@Tenaya.stanford.edu>
Subject: Spring faculty meeting
Is the April 26 (Tuesday) SSP lunch unmovable? The CS faculty meet
for lunch on Tuesdays, and thus many of us who might otherwise attend
the SSP lunch (me, for example) would not be able to come on a Tuesday.
-Nils Nilsson
∂17-Mar-88 2006 barwise@russell.stanford.edu Re: Spring faculty meeting
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 17 Mar 88 20:06:01 PST
Received: from russell.stanford.edu by csli.stanford.edu (3.2/4.7); Thu, 17 Mar 88 20:08:52 PST
Received: from localhost by russell.stanford.edu (3.2/4.7); Thu, 17 Mar 88 20:10:13 PST
To: nilsson@Tenaya.stanford.edu
Cc: hilbert@russell.stanford.edu, ssp-faculty@russell.stanford.edu
Subject: Re: Spring faculty meeting
In-Reply-To: Your message of Thu, 17 Mar 88 16:59:17 PST.
<8803180059.AA16715@Tenaya.stanford.edu>
Address: CSLI, Stanford University, Stanford, CA 94305 (415) 723-0110
Date: Thu, 17 Mar 88 20:10:12 PST
From: Jon Barwise <barwise@russell.stanford.edu>
I should have remembered that. Yes, we will try to move it. Thanks
for warning us.
∂19-Mar-88 1821 X3J13-mailer last meeting
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 19 Mar 88 18:21:52 PST
Date: 19 Mar 1988 21:21-EST
Sender: MATHIS@A.ISI.EDU
Subject: last meeting
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]19-Mar-88 21:21:18.MATHIS>
Thanks to all of you who participated in last week's meeting. I
think we had a very productive meeting. The results will be in
the minutes and reports from the various committees. The
committees are really working.
I have also noticed that some of you have already begun sending
out comments relative to last weeks discussions. Keep those
cards and letters coming.
Thanks, Bob
∂19-Mar-88 1844 X3J13-mailer minutes 3/88 mtg
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 19 Mar 88 18:44:21 PST
Date: 19 Mar 1988 21:43-EST
Sender: MATHIS@A.ISI.EDU
Subject: minutes 3/88 mtg
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]19-Mar-88 21:43:46.MATHIS>
Minutes of the X3J13 Meeting, Palo Alto, March 16, 17, 1988.
Wednesday, March 16
09:00 am Item 1, 2a, 2b., 3, 4.
Item 1. 2a. Call to Order. Bob Mathis
Item 2b. Introduction of attendees. Attendees list.
Item 4. Approval of minutes
Item 3. Approval of agenda.
Item 2d. Attendees were reminded to keep discussions short so that
entire agendas could be covered.
The method of distribution for backup will be netmail with
the following exceptions: documents which are too large for
netmail will be mailed, documents will be available in hard
copy at the meeting, and arrangements will attempt to be made
for those people requesting hard cover mailings.
Cambridge, June 13-17. Committee mtg Wed, Thur.
Washington, October, Committee mtg Wed, Thur.
Hawaii, Jan.
09:10 am. Item 2c.
Item 2c. Report on ISO meetings, Paris, Feb 24-25, 1988. Dick Gabriel.
Countries participating were: Canada, Commission of the
European Community, Denmark, France, Germany, Japan,
Netherlands, Switzerland, UK, and US. Position of each
country presented, demonstrating wide diversity of opinion.
US Delegation included Dick Gabriel (project editor), Bob
Mathis, Will Clinger (project editor), Patrick Dussud, Larry
Masinter, Kent Pitman, Thom Linden, and John McCarthy.
Votes were taken which Dick Gabriel stated to the ISO group
had to be tentative on his part since he wished to come back
to this group for advice.
1. Majority vote was to concentrate first on a short-term
standard.
2. Some characteristics of the standard, by preference:
portable, efficient, clear semantics and simple semantics.
3. Most popular departure points were Common Lisp, Scheme,
and Eulisp.
4. The majority vote was for the name ISLISP.
5. Responsibilities were distributed. US volunteered
documents, rather than volunteers, for OOP, Functions,
Macros, Multiprocessing, Character Set, Windows,
Conditions, Iteration. Bob Mathis emphasized to X3J13 that
individuals could volunteer.
10:30 am Break
10:45 am Item 5
Item 5 (Doc: 88-002, 88-003, 88-004), Guy Steele.
Chapter 1 and 2.
The purpose of having an implementation result being undefined
was shown to be that of having the result be undocumented so
that a user could not rely on the result (for example, use of
multiple ELSE in an IF).
JonL White expressed concern that the use of the name "symbol
class" would continue a direction, which he considered
misguided, on nomenclature on symbol-value. A broader
question was raised as one reply that CLOS committee could
not address the entire issue of nomenclature in Common Lisp.
Expressed concerns: voting on chapters 1 and 2 separate from
3; voting on chapters 1 and 2 without knowing how it fits
into CLTL; voting at this meeting rather than waiting until
reply from written comments integrated into chapters 1 and 2;
defining a continuing mechanism (ie. cleanup committee) for
continuing changes to chapters 1 and 2); defining a new
subcommittee to define the layering of Common Lisp.
12:10 pm Item 6 Lunch
1:00 pm Item 7 CLOS Continuation
The following motion was moved and unanimously passed:
X3J13 and the CLOS Subcommittee agree on the following:
1. X#J13 members will read and give comments on Document
88-002 (Chapters 1 and 2 of the CLOS Specification) by April
21, 1988. Comments can be sent via electronic mail to:
common-lisp-object-system@sail.stanford.edu
2. The CLOS Subcommittee will consider all comments, prepare
a revised draft of Chapters 1 and 2, and prepare a written
summary of how they addressed the comments. These documents
will be distributed to X3J13 members in advance of the June
X3J13 meeting.
3. At the June meeting, the X3J13 Committee will vote
whether or not to accept Chapters 1 and 2 out of the CLOS
Subcommittee.
Vote of thanks to the CLOS Subcommittee for their
work was moved and unanimously passed.
Chapter 3.
Gregor Kiczales presented a summary of the status of the
Metaobject Protocol (Chapter 3 of the CLOS Specification
88-003).
Moved by Barry Margolin, seconded by Dan Bobrow.
Approve the general direction of the Metaobject Protocol of
CLOS (as specified in 88-003), and recommend that the Object
Subcommittee continue working on this with an eye toward a
new draft prior to the fall meeting with the expectation that
we would then have a one month written comment period prior
to the winter meeting followed by a vote to move it out of
subcommittee at the winter meeting. Motion passed
unanimously by voice vote.
2:30 pm Afternoon break
2:40 pm Item 10
Item 10 Cleanup, Larry Masinter.
Moved and passed by voice vote 10-7: To postpone the vote on
the bundled cleanup issues until tomorrow morning.
Bundled Issues:
ADJUST_ARRAY_DISPLACEMENT
APPEND_DOTTED
AREF_1D
ASSOC_RASSOC_IF_KEY
COLON_NUMBER
DEFVAR_DOCUMENTATION
DISASSEMBLE_SIDE_EFFECT
DO_SYMBOLS_DUPLICATES
DRIBBLE_TECHNIQUE
FLET_DECLARATION
FORMAT_COMMA_INTERVAL
FORMAT_COLON_UPARROW_SCOPE
FUNCTION_TYPE_KEY_NAME
GET_SETF_METHOD_ENVIRONMENT
KEYWORD_ARGUMENT_NAME_PACKAGE
PATHNAME_STREAM
PATHNAME_SYMBOL
PUSH_EVALUATION_ORDER
REDUCE_ARGUMENT_EXTRACTION
SHADOW_ALREADY_PRESENT
SHARPSIGN_PLUS_MINUS_PACKAGE
Unbundled Issues to be separately considered:
COMPILER_WARNING_BREAK
DECLARE_MACROS
FUNCTION_TYPE_REST_LIST_ELEMENT
FUNCTION_TYPE
SETF_FUNCTION_VS_MACRO
SEQUENCE_FUNCTIONS_EXCLUDE_ARRAYS
Larry Masinter led a discussion of cleanup issues which were
not sent to members prior to this meeting. For back mail on
a particular issue, send to:
masinter.pa@xerox.com.
Otherwise, see:
cl-cleanup@sail.stanford.edu.
05:05 pm Item 8 Meeting adjourned
Thursday, March 17
09:00 am Item 9
Item 9 Call to Order. Bob Mathis
09:15 am Item 10
Item 10 Cleanup, Larry Masinter
Moved by Dave Slater and seconded by Dan Pierson that the
bundled cleanup issues be accepted in a single vote and
the unbundled cleanup issues be accepted on separate votes.
The motion passed by unanimous voice vote.
COMPILER_WARNING_BREAK - A majority voice vote and a majority
company vote rejected the addition of COMPILER_WARNING_BREAK.
DECLARE_MACROS - Cris Perdue moved and Dick Gabriel seconded
a motion to stop discussion of DECLARE_MACROS. The motion
was passed by majority company vote. A majority company vote
accepted the addition of DECLARE_MACROS.
FUNCTION_TYPE_REST_LIST_ELEMENT - JonL White moved and Barry
Margolin seconded to table the previous motion to accept
FUNCTION_TYPE_REST_LIST_ELEMENT. The motion passed by
company vote 16-7.
FUNCTION_TYPE - Unanimous straw vote showed a belief that
redefinition of some type was necessary (FUNCTION_TYPE).
Unanimous straw vote showed that some change was needed
rather than the status quo. Majority (all but 2) straw vote
showed sentiment was against the conservative proposal.
Majority straw vote passed to not accept 2E as written, but
rather to amend 2E so that FUNCALL and APPLY can accept
anything that can be coerced to a function. A straw vote by
company was called to accept 6B. The straw vote passed
(14-7-4). Barry Margolin moved and Jim Antonisse seconded to
table the previous motion to accept FUNCTION_TYPE and to ask
the subcommittee to resubmit FUNCTION_TYPE with changes in
line with the straw votes. The motion passed (20-1-3). Dick
Gabriel moved and Dan Pierson seconded that the conservative
proposal be immediately accepted. This was unanimously
rejected by company vote (0-25-0).
11:15 pm Break
11:30 pm General comments
SETF_FUNCTION_VS_MACRO - As agreed yesterday, this issue is
tabled until after the function specification report.
SEQUENCE_FUNCTIONS_EXCLUDE_ARRAYS - The motion to generalize
SEQUENCE_FUNCTIONS_EXCLUDE_ARRAYS passed (15-6-3). Dick
Gabriel moved and Dan Pierson seconded that the discussion be
reopened. The motion passed by majority company vote. David
Moon moved to call the question to a vote to generalize SEQ
... The vote was rejected (3-18-3).
12:15 pm Item 11 Lunch
01:15 pm Item 12
Item 12 Status of Standard, Kathy Chapman
After describing the phases of document preparation, concern
was expressed whether an early version of the document would
be available or whether the cost in time and money would make
an early version impractical. A straw vote unanimously
passed to require members wishing to review the document to
specifically ask for the document and pay for duplication and
mailing. Kathy has been asked for a more detailed plan for
distribution and review at the next meeting.
02:00 pm Status of Scheme Standard, David Bartley
Scheme standardization is under consideration in a
microprocessor group of IEEE. This umbrella is also working
toward the standardization of MODULA/2, SMALLTALK, FORTH,
and PILOT.
02:15 pm Item 15
Item 15 Other committee reports
MACRO SUBCOMMITTEE REPORT, Julian Padget
There has been no subcommittee meeting since the last X3J13
meeting. Two people responded to a request for interesting
macros. Julian reiterated his request and also asked for new
volunteers. Send any information to:
padget@maths.bath.ac.uk
CHARACTER SUBCOMMITTEE REPORT, Thom Linden
A detailed proposal was presented of the work done to date.
Several strawvotes presented moderate support for the
direction of parts of the proposal.
03:20 pm Break
03:30 pm Announcements, Bob Mathis
03:35 pm Item 15 (cont.)
Item 15 ITERATION SUBCOMMITTEE REPORT, Jon L. White
The status of LOOPS and the work being currently done in OSS
was described. Pavel Curtis discussed ITERATE and GATHERING.
Concern was expressed with the concept of the iteration
constructs being "portable, optional".
COMPILER SUBCOMMITTEE REPORT, Steve Haflich
Steve described a model to be used to figure out what a compile
file does.
04:35 pm Item 14
Item 14 Condition System, Andy Daniels
Comments have stopped so version 18 of proposal seems
stabilized. Open issues are still open but can be completed
as cleanup. Straw vote showed that the directions are right
and that the proposal should be presented for acceptance at
the June meeting. Volunteers are requested to flesh out
specification.
05:00 pm Item 13
Item 13 Function Specs, JonL White
JonL described the overview and goals of the specifications. A
proposal is forthcoming. Unanimous straw vote to encourage
the subcommittee to continue its work and to present a
proposal.
05:35 am Item 10 (cont.)
Item 10 Cleanup, Larry Masinter
SETF_FUNCTION_VS_MACRO - Unanimous straw vote showed that
discussion should be closed. Dan Pierson moved and Guy Steele
seconded the motion to table SETF... The motion passed by a
majority voice vote. Committee thanked Larry Masinter for
bringing forward these issues in such good condition and
Larry thanked his subcommittee.
06:00 Item Adjournment
Minutes submitted by Mary S. Van Deusen (March 17, 1988)
∂21-Mar-88 0756 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: nice looking graphs
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 88 07:56:28 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Mon 21 Mar 88 07:50:48-PST
Received: by lindy.stanford.edu; Mon, 21 Mar 88 07:55:10 PST
Received: by Forsythe.Stanford.EDU; Mon, 21 Mar 88 07:54:17 PST
Received: by BYUADMIN (Mailer X1.25) id 8395; Mon, 21 Mar 88 08:52:55 MST
Date: Mon, 21 Mar 88 08:51:55 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Gabriel Robins <oahu!gabriel%locus.ucla.edu@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Gabriel Robins <oahu!gabriel%locus.ucla.edu@forsythe.stanford.edu>
Subject: Re: nice looking graphs
To: Local Distribution <aflb.tn@sushi.stanford.edu>
Greetings,
In response to the various queries regarding the automatic pictorial
display of graphs, I am submitting a summary of the system I have developed
to do same. The sources, as well as several papers on the subject, are also
available; please direct all inquiries to GABRIEL@VAXB.ISI.EDU or to the
postal address given below.
Gabriel Robins
============================================================================
AI/Graphics tool availability update:
"The ISI Grapher: a Portable Tool for Displaying Graphs Pictorially"
Now available for the MacIntosh II and SUNs (as well as for Symbolics
and TI Explorers).
============================================================================
Due to the considerable interest drawn by the ISI Grapher so far, I am
posting this abstract summarizing its function and current status. The ISI
Grapher Common LISP sources are now available to both domestic and foreign
sites.
A paper describing this effort is now available, entitled: "The ISI
Grapher: a Portable Tool for Displaying Graphs Pictorially." A more
detailed document is also available, called "The ISI Grapher Manual." It
describes the implementation, usage, data-structures, and algorithms of the
ISI Grapher.
The CommonLisp sources are also available. It currently runs on Symbolics
versions 6 & 7, TI Explorers versions 2 & 3, MacIntosh II (under both Coral
Allegro LISP and ExperCommon LISP), and SUNs (under Franz and Lucid, using X).
Ports to other machines, such as HP Bobcats, are currently in the planning.
If you know of any other ports, both completed or planned, please let me know.
If you would like to have the paper and/or the sources, please forward your
name and postal address to "gabriel@vaxb.isi.edu" or to:
Gabriel Robins
Intelligent Systems Division
Information Sciences Institute
4676 Admiralty Way
Marina Del Rey, Ca 90292-6695
ExperTelligence Inc. is currently marketing the ISI Grapher for the MacIntosh
under ExperCommon LISP. You may contact them directly regarding the Mac
version: ExperTelligence Inc., 559 San Ysidro Road, Santa Barbara, CA 93108
(805) 969-7871.
============================================================================
The ISI Grapher
February, 1988
Gabriel Robins
Intelligent Systems Division
Information Sciences Institute
The ISI Grapher is a set of functions that convert an arbitrary graph
structure (or relation) into an equivalent pictorial representation and
displays the resulting diagram. Nodes and edges in the graph become boxes
and lines on the workstation screen, and the user may then interact with the
Grapher in various ways via the mouse and the keyboard.
The fundamental motivation which gave birth to the ISI Grapher is the
observation that graphs are very basic and common structures, and the belief
that the ability to quickly display, manipulate, and browse through graphs may
greatly enhance the productivity of a researcher, both quantitatively and
qualitatively. This seems especially true in knowledge representation and
natural language research.
The ISI Grapher is both powerful and versatile, allowing an
application-builder to easily build other tools on top of it. The ISI NIKL
Browser is an example of one such tool. The salient features of the ISI
Grapher are its portability, speed, versatility, and extensibility. Several
additional applications were already built on top of the ISI Grapher,
providing the ability to graph lists, flavors, packages, divisors, functions,
LOOM hierarchies, and Common-Loops classes.
Several basic Grapher operations may be user-controlled via the specification
of alternate functions for performing these tasks. These operations include
the drawing of nodes and edges, the selection of fonts, the determination of
print-names, pretty-printing, and highlighting operations. Standard
definitions are already provided for these operations and are used by default
if the application-builder does not override them by specifying his own
custom-tailored functions for performing the same tasks.
The ISI Grapher now spans about 200K of CommonLisp code. The 105-page
ISI Grapher manual is available; this manual describes the general ideas, the
interface, the application-builder's back-end, the algorithms, the
implementation, and the data structures. A shorter paper is also available,
and includes hardcopy samples of the screen during execution. The ISI Grapher
presently runs on both Symbolics (versions 6 & 7), TI Explorer workstations
(versions 2 & 3), MacIntosh II (under both Coral Allegro LISP and ExperCommon
LISP), and SUNs (under Franz and Lucid, using X); ports to other machines are
being planned.
If you are interested in more information, the sources themselves, or just
the paper/manual, please feel free to forward your name and postal address to
"gabriel@vaxb.isi.edu" or write to "Gabriel Robins, Information Sciences
Institute, 4676 Admiralty Way, Marina Del Rey, Ca 90292-6695 U.S.A."
============================================================================
∂21-Mar-88 0934 TAJNAI@Score.Stanford.EDU Sunrise Club tomorrow a.m.
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 88 09:34:32 PST
Date: Mon 21 Mar 88 09:23:48-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Sunrise Club tomorrow a.m.
To: faculty@Score.Stanford.EDU, phd@Score.Stanford.EDU
cc: chequer@Sierra.Stanford.EDU
Message-ID: <12384134721.24.TAJNAI@Score.Stanford.EDU>
This is a reminder that the quarterly meeting of the
Sunrise Club will be held tomorrow 7:30 a.m. at
Tresidder.
If you can attend, and have not yet responded, please do so
asap.
Carolyn
p.s. Proceeds from the Sunrise Club go towards SOE Fellowships.
CSD will receive 6 fellowships for 88/89. Also, remember to let
me know if there is a small start-up company we should invite to join.
We can include a rep as a guest for an introduction to the program.
-------
∂21-Mar-88 1116 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU statement to Congress on supercomputers
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 88 11:16:27 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 21 Mar 88 11:10:10-PST
Date: 21 Mar 88 1113 PST
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: statement to Congress on supercomputers
To: faculty@SCORE.STANFORD.EDU
Here's the statement I propose to send to the Congressional
Committee. I hope those who endorsed the idea will endorse the
statement.
%super[w88,jmc] Statement on supercomputers
We are concerned that the present NSF emphasis on
supercomputer centers and engineering research centers
is having an adverse effect on research in computer
science by drastically reducing NSF support for individual
and small group research in computer science.
As in other sciences, almost all of the advances in computer
science to date has been the result of research by individuals and small
groups. This is the most flexible way of doing research and the one that
gives the best opportunities for young researchers to make innovations.
The only justification for a large basic research organization is when
expensive research facilities, e.g. a particle accelerator, is necessary
to do the research at all. In the early days, laboratories with
tens (but not hundreds) of researchers played an important role
in computer science, because laboratories of that size were necessary in
order to afford adequate computer facilities. With the advent of
computer workstations, the cost of providing an individual researcher
with individual computer facilities for most kinds of computer research
is now in reasonable relation to his salary. Departmental facilities
provide an important supplement.
The emphasis on research centers leads in the long run (ten years)
to domination of research by established ideas and by the most
active administrators rather than by the best researchers.
For these reasons we believe the recent emphasis on
supercomputer centers and engineering research centers has
had significant detrimental side-effects on American computer
science. The symptom noted is that proposals with excellent
ratings by the reviewers are often not funded or funded at
very reduced levels.
The issue of individual grants vs. supercomputer centers
and engineering research centers is independent of the issue of merit
vs. geography in the awarding of grants.
∂21-Mar-88 1154 STAGER@Score.Stanford.EDU End Quarter Grade Sheets
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 88 11:54:25 PST
Date: Mon 21 Mar 88 11:48:13-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: End Quarter Grade Sheets
To: faculty@Score.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12384161013.40.STAGER@Score.Stanford.EDU>
REMINDER:
Grade sheets are due today, Monday the 21st. Please contact me at 3-6094
or Stager@Score if you don't think you'll be able to meet the deadline.
Thanks.
-------
∂21-Mar-88 1255 @Score.Stanford.EDU:RPG@SAIL.Stanford.EDU Supercomputing Center Statement
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 88 12:55:39 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 21 Mar 88 12:50:23-PST
Date: 21 Mar 88 1254 PST
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Subject: Supercomputing Center Statement
To: faculty@SCORE.STANFORD.EDU
Although I agree with what I take to be the consensus on this issue, I
believe that the statement drafted by John will give a wrong impression.
Readers of the statement will believe that the signers believe that the
only progress that can be made in computer science is that made by
individuals or small groups. One can certainly define ``computer science''
in such a way this belief is true, but that definition will not correspond
to the commonly accepted definition. Also, I believe that some naive
remarks in the statement will tend to discredit it.
``We are concerned that the present NSF emphasis on supercomputer centers
and engineering research centers is having an adverse effect on research
in computer science by drastically reducing NSF support for individual and
small group research in computer science.''
[Is it known that the amount of support is drastically reduced or is it
the case that the absolute dollar amount is rising and the percentage
going to small researcher groups is dropping?]
``As in other sciences, almost all of the advances in computer science to
date has been the result of research by individuals and small groups.''
[This statement implies that the situation was simply fine before and
that no change is necessary. If almost all research money in the past has been
spent on small projects, the positive effects of spending some on large
projects is not known. One might argue that taking money away from a pool
for small research efforts is detrimental, but one shouldn't try to argue
that nothing will be gained by funding large efforts.]
``This is the most flexible way of doing research and the one that
gives the best opportunities for young researchers to make innovations.''
[Of course, young researchers want to get tenure, and a series of ``small
results'' is often the best strategy. You should clarify what you mean by
the ``most flexible way of doing research.'' Do you mean that NSF can
afford many more small projects than large ones or that a small research
group can change direction faster? I'm not sure the latter will be
universally recognized as an advantage.]
The only justification for a large basic research organization is when
expensive research facilities, e.g. a particle accelerator, is necessary
to do the research at all.
[This is false. This is an important or a primary justification, but it is
certainly not the only justification. How could one obtain results on
designing and building a large software system where the methodologies of
designing such systems form the field of study? I know of one European
project that is using existing hardware but which is re-writing all of the
software from the ground up according to some different software
principles. This project has 100 people and funding of $120 million for 5
years. They are not trying to conserve or acquire facilities. If your
definition of computer science rules out such activities as part of the
field, you should define your terms accordingly. That is, another reason
for a large research organization is that the magnitude of the project is
large.]
``In the early days, laboratories with tens (but not hundreds) of
researchers played an important role in computer science, because
laboratories of that size were necessary in order to afford adequate
computer facilities. With the advent of computer workstations, the cost
of providing an individual researcher with individual computer facilities
for most kinds of computer research is now in reasonable relation to his
salary. Departmental facilities provide an important supplement.''
[This ignores some other economies. Workstations have a large shared
component: the networks, the file servers, the printing systems for example.
Facilities personnel costs can be streamlined by using larger organizations.
Arguing from a basis of why work was organized in some particular way in
the past to present conditions must be carefully done.]
``The emphasis on research centers leads in the long run (ten years) to
domination of research by established ideas and by the most active
administrators rather than by the best researchers.''
[This will cause unnecessary argument. Research is always dominated by
established ideas due to human nature not due to large organizations.
Perhaps there is some additional effect from large organizations, but you
will have a hard time separating the effects. In judging NSF proposals one
often looks at how ``far out'' the proposal is to determine the liklihood
of success, and so there is a limiting factor already. This is not a
compelling part of the argument. Also, proposals are often granted to the
most active researchers rather than to the best researchers. A long track
record of competent results sways more than an off-beat proposal from a
new researcher.]
``For these reasons we believe the recent emphasis on supercomputer
centers and engineering research centers has had significant detrimental
side-effects on American computer science. The symptom noted is that
proposals with excellent ratings by the reviewers are often not funded or
funded at very reduced levels.''
[The conclusions don't follow from the symptom. Another possibility is
that there are more excellent proposals. The statement, I believe, ought
to be that funding for small projects should not be reduced in order to
create some large ones. Arguing that large projects are wrong or
inappropriate creates opposition. Argue the merits of small projects and
let the right people draw the conclusions for you. This statement is
rhetoric for rhetoric's sake. Another point is that you should define
what you would regard as evidence of ``detrimental side-effects on American
computer science,'' or at least think carefully about it. You have defined the
term as being synonymous with the number of small projects funded where most
would define it in terms of results. What symptom is there that supports
the claim that the rate of results has declined? The rest of the statement
argues that small projects produce more or better results than large ones,
but you have no evidence to support that claim.]
``The issue of individual grants vs. supercomputer centers
and engineering research centers is independent of the issue of merit
vs. geography in the awarding of grants.''
[This needs to be reworded or further explained. It sounds like an
afterthought. If these are independent considerations, then large centers
will be created based on someone's perception of their merit, and if that
has the side effect of funding fewer small projects, that's ok. However,
the rest of the statement is arguing about the merit of large projects as
large projects, and the conclusion you hope to reach is that funding for
large projects should be dropped in favor of small ones (or so it
appears).
I should point out that the last NSF review I did, which was last week,
rated the proposed work as excellent but downgraded the liklihood of
good results because the requested level of funding was unrealistically
low.]
-rpg-
∂21-Mar-88 1436 STAGER@Score.Stanford.EDU 1988/89 Course Scheduling
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 88 14:35:55 PST
Date: Mon 21 Mar 88 14:29:39-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: 1988/89 Course Scheduling
To: faculty@Score.Stanford.EDU
cc: stager@Score.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12384190400.37.STAGER@Score.Stanford.EDU>
A major project now looming is the gridding out of our 1988/89 course offerings
for next year's Courses and Degrees. Course descriptions have already been
submitted, so what I would appreciate from you now is the following:
---What courses do you plan on teaching for CS in 1988/89?
---What quarters would you like to teach them?
---What times and days do you prefer?
---If a potential TV course: Do you think it should be televised,
don't care if it's televised, or
refuse to have it televised?
Once again, thanks for your assistance.
Claire
-------
∂21-Mar-88 1944 @Sushi.Stanford.EDU:seidel@ernie.Berkeley.EDU theory/geometry talk at UCB
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 88 19:44:10 PST
Received: from ernie.Berkeley.EDU by Sushi.Stanford.EDU with TCP; Mon 21 Mar 88 19:37:36-PST
Received: by ernie.Berkeley.EDU (5.58/1.26)
id AA20024; Mon, 21 Mar 88 19:43:48 PST
Date: Mon, 21 Mar 88 19:43:48 PST
From: seidel@ernie.Berkeley.EDU (Raimund Seidel)
Message-Id: <8803220343.AA20024@ernie.Berkeley.EDU>
To: aflb.all@sushi.stanford.edu
Subject: theory/geometry talk at UCB
Small Sets Supporting Fary Embeddings of Planar Graphs
by
Richard Pollack
New York University
Wednesday, March 23
Bechtel 225A
Abstract:
We show that every plane graph with n vertices has a Fary
embedding (ie., a straight line embedding) on the 2n-4 by n-2 grid and
provide and O(n) space , O(nlogn) time algorithm to effect this embedding.
This grid size turns out to be asymptotically optimal.
Previously it had been unknown whether one can always
find a polynomial sized grid to support such an embedding.
On the other hand, we show that any set F, which can support a
Fary embedding for every planar graph of size n, has cardinality at least
n+(1-o(1))sqrt(n), which settles a problem of Mohar.
This work was joint with Hubert De Fraysseix and Janos Pach.
∂22-Mar-88 0840 @Sushi.Stanford.EDU:seidel@ernie.Berkeley.EDU time for theory/geometry talk at UCB
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Mar 88 08:40:32 PST
Received: from ernie.Berkeley.EDU by Sushi.Stanford.EDU with TCP; Tue 22 Mar 88 08:34:13-PST
Received: by ernie.Berkeley.EDU (5.58/1.26)
id AA03167; Tue, 22 Mar 88 08:40:23 PST
Date: Tue, 22 Mar 88 08:40:23 PST
From: seidel@ernie.Berkeley.EDU (Raimund Seidel)
Message-Id: <8803221640.AA03167@ernie.Berkeley.EDU>
To: aflb.all@sushi.stanford.edu
Subject: time for theory/geometry talk at UCB
Contrary to the impression I might have left you with, Ricky Pollack
will not talk all day about Fary Embeddings on Wednesday, but
starting at 3pm, 225A Bechtel.
SR
∂22-Mar-88 1147 @Score.Stanford.EDU:cheriton@Pescadero.stanford.edu Re: Supercomputing Center Statement
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Mar 88 11:47:34 PST
Received: from Pescadero by SCORE.STANFORD.EDU with TCP; Tue 22 Mar 88 11:41:37-PST
Received: by Pescadero (5.54/Ultrix2.0-B)
id AA02362; Tue, 22 Mar 88 11:46:37 PST
Date: Tue, 22 Mar 88 11:46:37 PST
From: "David Cheriton" <cheriton@pescadero.stanford.edu>
Message-Id: <8803221946.AA02362@Pescadero>
To: RPG@sail.stanford.edu, faculty@score.stanford.edu
Subject: Re: Supercomputing Center Statement
I think Dick is being a bit picky but I agree with his general point.
Perhaps the statement should make clear that:
1) Supercomputers are just supercolliders in drag; they have almost nothing
to do with Computer Science. The commercial market for Crays is small
and the ability to generate Crayettes, like Ardent Computers, etc.
may be far more important than spending more money on physicists.
2) (as a quasi-separate issue) Stable and significant funding for indivuduals
and small groups of computer scientists is important and currently not
adequate.
3) There is a trend to transfers funds from 2) to 1) which must be
stopped, at least by protecting 2).
∂22-Mar-88 1312 @Score.Stanford.EDU:dill@amadeus.stanford.edu supercomputers
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Mar 88 13:11:59 PST
Received: from amadeus.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 22 Mar 88 13:06:17-PST
Received: by amadeus.stanford.edu; Tue, 22 Mar 88 13:11:24 PST
Date: Tue, 22 Mar 88 13:11:24 PST
From: David Dill <dill@amadeus.stanford.edu>
Subject: supercomputers
To: faculty@score.stanford.edu, rpg@sail.stanford.edu
It is probably very important to avoid introducing irrelevant issues,
which may distract from the main point and may offend other interest
groups.
It seems to me that the important point is that funding for supercomputers
should not be mistaken for funding for Computer Science. Although perhaps
not completely disjoint, funding for supercomputer centers benefits few
computer scientists and contributes little of main body of Computer Science.
The rest of Computer Science, which isn't very expensive compared
with supercomputer centers, contributes greatly to American
economic competitiveness (this seems to be an important buzzword these
days); it would be a serious mistake to reduce funding.
This argument can be made without attacking supercomputing --
supercomputing may be wonderful, it just shouldn't be mistaken
for Computer Science. It also need not drag in issues such as
large vs. small projects.
∂22-Mar-88 1350 @Score.Stanford.EDU:WIEDERHOLD@SUMEX-AIM.Stanford.EDU Re: supercomputers
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Mar 88 13:50:19 PST
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 22 Mar 88 13:44:19-PST
Date: Tue, 22 Mar 88 13:50:06 PST
From: Gio Wiederhold <WIEDERHOLD@SUMEX-AIM.Stanford.EDU>
Subject: Re: supercomputers
To: dill@amadeus.stanford.edu
cc: faculty@score.stanford.edu, rpg@sail.stanford.edu
Reply-To: RESTORE-DRAFT SEND SET
In-Reply-To: Message from "David Dill <dill@amadeus.stanford.edu>" of Tue, 22 Mar 88 13:14:21 PST
Message-ID: <12384445344.26.WIEDERHOLD@SUMEX-AIM.Stanford.EDU>
We know that Supercomputers and Computer Science are distinct. Congress does
not. I agree that the focus of the message can be sharpened, but I also agree
with John on small versus large. The large projects cited earlier are not
producing much good science, certainly not the German ones, who are staffed
by `research bureaucrats'. We need to prove some large scale CS theories and
concepts in practice, but for that cooperation with and feedback from
industry is the preferred model for me.
Gio
-------
∂22-Mar-88 1406 @Score.Stanford.EDU:RPG@SAIL.Stanford.EDU Supercomputing Centers
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Mar 88 14:06:36 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 22 Mar 88 14:00:54-PST
Date: 22 Mar 88 1402 PST
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Subject: Supercomputing Centers
To: faculty@Score.Stanford.EDU
I think it's important that if a group of significant computer scientists
are writing a letter to Congress, that letter ought to be sharp and make
its points clearly and with substantiation. A silly letter from an
important group is still a silly letter. There is evidence that Congress
does not like to be talked down to by experts, and the evidence I have
involves computer scientists.
I was under the impression that the consensus was about supercomputing
centers versus computer science funding. It might be reasonable to draft a
second letter concerning small projects versus large projects, but it
demonstrates muddy thinking to mix up funding for large computers with
funding for large projects. If a letter were drafted advocating small
projects over large ones, I'd probably draft the opposite letter and
gather an equally compelling list of signatories, but that is a separate
question.
-rpg-
∂22-Mar-88 1457 @Sushi.Stanford.EDU:MAYR@Score.Stanford.EDU paco seminar this Friday
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Mar 88 14:57:11 PST
Received: from Score.Stanford.EDU by Sushi.Stanford.EDU with TCP; Tue 22 Mar 88 14:48:02-PST
Date: Tue 22 Mar 88 14:46:50-PST
From: Ernst W. Mayr <MAYR@Score.Stanford.EDU>
Subject: paco seminar this Friday
To: paco@Navajo.Stanford.EDU, aflb.local@Sushi.Stanford.EDU
Message-ID: <12384455671.41.MAYR@Score.Stanford.EDU>
paco seminar, Friday, March 25, at 1:00pm, in MJH352:
Speaker: Simon Kasif
Department of Computer Science
The Johns Hopkins University
Title: On the Complexity of Incremental Parallel Computations
Abstract:
In this talk we discuss the problem whether we can devise efficient parallel
algorithms for incrementally updating solutions to problems that have been
shown to be inherently sequential. In many cases, it has been shown that
knowing the solution to P0 allows one to store a relatively small data
structure that can subsequently used in a parallel algorithm for computing
P1,P2,... that vary only slightly from each other. We define a general
framework to study the complexity of incremental parallel computations. We
give several examples where an incremental version of a problem is easier than
recomputing the solution from scratch. Subsequently, we show that for a range
of important problems recomputing a solution in parallel is as difficult as
computing it without any previous knowledge. Our results allow us to relate
incremental parallel complexity to standard parallel complexity notions.
Additionally, we prove several basic results that shed light on the
relationships between parallel time and the auxiliary data structure that must
be maintained to improve performance.
-------
∂23-Mar-88 1023 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu cycle detection in graphs
Received: from Sushi.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Mar 88 10:23:43 PST
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Wed 23 Mar 88 07:20:57-PST
Received: by lindy.stanford.edu; Wed, 23 Mar 88 07:25:32 PST
Received: by Forsythe.Stanford.EDU; Wed, 23 Mar 88 07:24:26 PST
Received: by BYUADMIN (Mailer X1.25) id 5383; Wed, 23 Mar 88 08:24:26 MST
Date: Wed, 23 Mar 88 09:15:18 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
David Cabana <uflorida!beach.cis.ufl.edu!drc%gatech.edu@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: David Cabana <uflorida!beach.cis.ufl.edu!drc%gatech.edu@forsythe.stanford.edu>
Subject: cycle detection in graphs
To: Local Distribution <aflb.tn@sushi.stanford.edu>
I am looking for literature on algorithms to detect cycles in
directed graphs. Ideally, I would like to see some analysis
of the time/space performance of the algorithms, maybe even
some pseudocode or program listings. I have looked at a few
books on graph theory, but didn't see anything along these
lines. Can anyone suggest some suitable references? Your
help will be appreciated.
∂23-Mar-88 1333 TAJNAI@Score.Stanford.EDU AT&T Bell Fellowship
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Mar 88 13:33:06 PST
Date: Wed 23 Mar 88 13:24:05-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: AT&T Bell Fellowship
To: craig@bird.Stanford.EDU, wolverton@Sushi.Stanford.EDU,
dhs@Portia.Stanford.EDU
cc: hayes-roth@SUMEX-AIM.Stanford.EDU, faculty@Score.Stanford.EDU,
bergman@Score.Stanford.EDU
Message-ID: <12384702752.39.TAJNAI@Score.Stanford.EDU>
We nominated 3 outstanding students for the AT&T Bell Fellowship,
however, only one fellowship is available for Stanford CSD.
We congratulate David Salesin on being chosen as the 1988/89
AT&T Fellow.
Carolyn Tajnai
-------
∂23-Mar-88 1600 @Score.Stanford.EDU:tanya@mojave.stanford.edu SEMINAR
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Mar 88 16:00:01 PST
Received: from mojave.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 23 Mar 88 15:53:43-PST
Received: by mojave.stanford.edu; Wed, 23 Mar 88 15:50:37 PST
Date: 23 Mar 1988 1550-PST (Wednesday)
From: Tanya Walker <tanya@mojave.stanford.edu>
To: Faculty@score.stanford.edu, Cis-Building@glacier.stanford.edu,
Su-Events@score.stanford.edu
Cc: Tanya@mojave.stanford.edu
Subject: SEMINAR
Computer Science Department
Margaret Jack
Room 252
3:00-4:30
March 30, 1988
A Mechanism for Efficient Debugging of Parallel Programs
Bart Miller
Computer Sciences Department
University of Wisconsin-Madison
We will address the design and implementation of an integrated
debugging system for parallel programs running on shared memory
multi-processor (SMMP). We describe the use of flowback analysis to
provide information on causal relationships between events in a
program's execution without re-executing the program for debugging. A
mechanism called "incremental tracing" is introduced, that, by using
semantic analyses of the debugged program, makes the flowback analysis
practical with only a small amount of trace generated during
execution. We extend flowback analysis to apply to parallel programs
and describe a method to detect race conditions in the interactions of
the co-operating processes.
∂23-Mar-88 1758 TAJNAI@Score.Stanford.EDU How Faculty can help the Forum
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Mar 88 17:58:27 PST
Date: Wed 23 Mar 88 16:30:48-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: How Faculty can help the Forum
To: faculty@Score.Stanford.EDU
cc: hiller@Score.Stanford.EDU
Message-ID: <12384736744.39.TAJNAI@Score.Stanford.EDU>
Microsoft joined the Forum back when they were a small start up company
and growing so fast they didn't have their act together, and they
dropped out in 1984. Over the years I tried to get them back, but
no luck.
A couple of weeks ago David Cheriton received a computer message from
someone at Microsoft asking him to work with them on a research project.
David immediately forwarded the message to me and asked their Forum
status. After I briefed him, he responded to Microsoft that the
first step was for them to join the Forum. I received a phone call
from Microsoft asking for information and sent the material out on
March 16. I just had a call; they are joining effective April 1.
David will receive a finder's fee of $1500/year for the first 3 years
of their membership and he will be the liaison, $2500 year.
My thanks to Dave, and I hope others of you will follow his example.
Carolyn
-------
∂23-Mar-88 1759 CHANDLER@Score.Stanford.EDU Faculty Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Mar 88 17:59:47 PST
Date: Wed 23 Mar 88 16:44:26-PST
From: Joyce R. Chandler <CHANDLER@Score.Stanford.EDU>
Subject: Faculty Meeting
To: faculty@Score.Stanford.EDU
cc: bureaucrats@Score.Stanford.EDU
Message-ID: <12384739226.15.CHANDLER@Score.Stanford.EDU>
A reminder...faculty meeting scheduled for March 29, 1988 - 2:15-4:00 in
MJH-146.
Thanks.
-------
∂24-Mar-88 1135 ULLMAN@Score.Stanford.EDU ERC's
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Mar 88 11:35:24 PST
Date: Thu 24 Mar 88 11:28:54-PST
From: Jeffrey D. Ullman <ULLMAN@Score.Stanford.EDU>
Subject: ERC's
To: faculty@Score.Stanford.EDU
Message-ID: <12384943929.27.ULLMAN@Score.Stanford.EDU>
I reply to RPG's comment on JMC's proposed statement:
I think John wisely did not get too specific about what is happening,
because attacks on the problem don't play well in Peoria. However,
it is not hard to see that ERC money largely goes to second or third
rate places, i.e., to places where computer scientists are so
weak that most or all of them cannot qualify for an individual
NSF grant. This is an artifact of someone's (probably Eric Bloch's)
theory that if you take a bunch of mediocre minds from different
fields, and make them work on a common problem, they will produce
first-rate results.
In every area I know about, the pool of NSF money has grown at inflation
plus-or-minus a few percent. Thus, ERC money has the clear effect
of taking resources away from people who were considered fundable
as individuals, and giving it to people who were not.
---jdu
-------
∂24-Mar-88 1251 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Responses to cycle detection in Graphs
Received: from polya.stanford.edu by SAIL.Stanford.EDU with TCP; 24 Mar 88 12:51:23 PST
Received: from Sushi.Stanford.EDU by polya.stanford.edu (5.54/inc-1.2)
id AA25210; Thu, 24 Mar 88 12:51:35 PST
Message-Id: <8803242051.AA25210@polya.stanford.edu>
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Thu 24 Mar 88 12:46:28-PST
Received: by lindy.stanford.edu; Thu, 24 Mar 88 12:50:58 PST
Received: by Forsythe.Stanford.EDU; Thu, 24 Mar 88 12:50:09 PST
Received: by BYUADMIN (Mailer X1.25) id 1920; Thu, 24 Mar 88 13:48:28 MST
Date: Thu, 24 Mar 88 14:17:43 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Victor S. Miller" <victor@ibm.com>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Victor S. Miller" <victor@ibm.com>
Subject: Responses to cycle detection in Graphs
To: Local Distribution <aflb.tn@sushi.stanford.edu>
-----
Date: Thu, 24 Mar 88 08:41:24 EST
>From: shallcrs@gvax.cs.cornell.edu (David Shallcross)
Subject: Re: cycle detection in graphs
You might look in Aho, Hopcroft, and Ullman's The Design and Analysis
of Computer Algorithms, section 5.5 on finding the strongly connected
components of a directed graph. This can be done in time linear in the
number of edges. A simpler algorithm, although no better than linear, is
to attempt a topological sort, and catch failures.
d shallcross
gvax@cs.cornell.edu
-----
Date: 24 March 1988 09:50:07 CST
>From: U32799 at UICVM (Uri N. Peled 312-413-2156;h 383-8309)
Subject: Re: Cycle detection in digraphs
Since several shortest-path algorithms can detect negative cycles, you can
detect your cycles if all edge-lengths are negative. See the discussion in
E. L. Lawler, "Combinatorial Optimization, Networks and Matroids", Holt,
Rinehart and Winston, 1976.
-----
Date: Thu, 24 Mar 88 14:00:22 CST
>From: tom@ksuvax1.BITNET (Tom Pittman)
Subject: cycle detection in graphs
David Cabana might want to check the DeRemer & Pennello paper, "Efficient
Computation of LALR(1) Lookahead Sets" ACM TOPLAS 4(4) 615-649, which
contains a linear algorithm for finding "strongly connected components"
(cycles) in a directed graph.
∂24-Mar-88 1420 @Score.Stanford.EDU:RPG@SAIL.Stanford.EDU ERC and Supercomputing Centers
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Mar 88 14:20:29 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 24 Mar 88 14:14:16-PST
Date: 24 Mar 88 1418 PST
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Subject: ERC and Supercomputing Centers
To: faculty@Score.Stanford.EDU
Reading Jeff's message, it seems like there is a more delicate point in
this than I had imagined. I think the concept of ERC's is not necessarily
flawed, but the current implementation might be. This requires carefully
separating out the arguments about implementation from the concept, but
that might result in bruised feelings if not done well. Also, it sounds
like a separate (or at least separable) issue from supercomputing centers
versus research funds.
I still suggest that the letter from Stanford CSD address the
supercomputing centers issue while a second letter address ERC's in their
current incarnations. I imagine that the second letter could talk about
the relatively higher quality of research required from an ERC so that
funding for individual researchers is jeopardized in only unusual
circumstances. Arguing against the concept of (very few) large projects
from first principles seems like an invitation to ridicule when there is
an important point to be made.
I believe that a few large projects should be funded, and while I imagine
that the bulk of people working a particular large project will be lesser
lights than the principal, I also assume that the principal, the cast of
characters, and the large project must represent at least as high if not
considerable higher quality than some number of smaller projects.
-rpg-
∂24-Mar-88 1937 emma@russell.stanford.edu CSLI Calendar, March 24, 3:21
Received: from csli.stanford.edu by SAIL.Stanford.EDU with TCP; 24 Mar 88 19:37:35 PST
Received: from russell.stanford.edu by csli.stanford.edu (3.2/4.7); Thu, 24 Mar 88 17:35:51 PST
Received: by russell.stanford.edu (3.2/4.7); Thu, 24 Mar 88 17:35:59 PST
Date: Thu, 24 Mar 88 17:35:59 PST
From: emma@russell.stanford.edu (Emma Pease)
To: friends@russell.stanford.edu
Subject: CSLI Calendar, March 24, 3:21
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
24 March 1988 Stanford Vol. 3, No. 21
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR NEXT THURSDAY, 31 March 1988
12 noon TINLunch
Ventura Hall Reading: "Learning at the Knowledge Level"
Seminar Room by Tom Diettrich
Discussion led by Kurt Konolige
(konolige@bishop.ai.sri.com)
Abstract in next week's Calendar
2:15 p.m. CSLI Seminar
New building Panel Discussion on Compositionality
Conference Room Per-Kristian Halvorsen (halvorsen.pa@xerox.com),
Stanley Peters (peters@russell.stanford.edu), and
Craige Roberts (croberts@csli.stanford.edu)
Abstract below
3:30 p.m. Tea
New building
Courtyard
--------------
ANNOUNCEMENTS
Don't forget our celebration of the new building on Thursday, March
31. Kurt Konolige will lead a TINLunch on "Learning at the Knowledge
Level" by Tom Diettrich; and Stanley Peters, Kris Halvorsen, and Craige
Roberts will give a mini-symposium on compositionality. Beginning at
3:30 we will have an extended tea complete with hors d'oeuvres,
drinks, and a jazz band.
--------------
NEXT WEEK'S CSLI SEMINAR
Panel Discussion on Compositionality
Per-Kristian Halvorsen, Stanley Peters, and Craige Roberts
March 31
Compositionality, conceived as a strong constraint on the relationship
between sentential structures and interpretations, has been one of the
central issues in semantic theory. Since Montague's seminal work on
this question, a number of analyses of specific interpretive problems
have called into question whether we can maintain compositionality as
a guiding principle in constructing semantic theories. And some
recent theories call into question in a more general way whether
compositionality is the kind of constraint we want on semantic theory.
These include theories which take seriously the contribution of
contextual information to interpretation, including situation
semantics and discourse representation theory, and also the recent
work by Fenstad, Halvorsen, Langholm, and van Benthem exploring
constraint-based interpretative theories operating on unification
grammars. In this panel discussion, we will briefly consider how
compositionality has generally been understood in the semantic
literature, give an overview of what we take to be the central
problems that call its utility into question, and discuss some
alternative conceptions of how semantic theory can be appropriately
constrained.
∂25-Mar-88 0726 @Score.Stanford.EDU:tom@polya.stanford.edu March 29th DECday show at Stanford
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Mar 88 07:26:28 PST
Received: from polya.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 25 Mar 88 07:19:36-PST
Received: by polya.stanford.edu (5.54/inc-1.2)
id AA12814; Fri, 25 Mar 88 07:24:19 PST
Date: Fri, 25 Mar 88 07:24:19 PST
From: tom@polya.stanford.edu (Tom Dienstbier)
Message-Id: <8803251524.AA12814@polya.stanford.edu>
To: csdd@score.stanford.edu, faculty@score.stanford.edu,
nethax@jessica.stanford.edu
Subject: March 29th DECday show at Stanford
DIGITAL EQUIPMENT'S DISTRIBUTED WORKSYSTEMS
-------------------------------------------
Sponsord by Stanford Academic Information Resources
DATE: Tuesday, March 29th
TIME: 10:00 a.m. - 2:00 p.m.
LOCATION: Stanford Tresidder Student Union, 2nd Floor, Oak Lounge
****************************************************************************
AGENDA
------
1. PRESENTATIONS
DIGITAL: INVESTING IN PERFORMANCE TECHNOLOGY
--------------------------------------------
11:00 a.m. - 12:00 p.m "High-End Technology"
Presented by: Paul McEnroe
Group Manager
Digital Equipment Corporation
Former President and CEO of Trilogy
Engineer's Degree in Electrical Engineering, Stanford Univ.
12:15 p.m. - 1:15 p.m. "Low-End Technology"
Presented by: Skip Garvin
Worksystems Marketing Manager
Digital Equipment Corporation
II. DEMONSTRATIONS OF WORKSYSTEMS SOLUTIONS
10:00 a.m. - 2:00 p.m.
----------------------
*InterViews *Oracle
*X Window System *VAXstation 8000 (3D Graphics)
*Network Monitoring *SDRC (Mechanical CAE)
*Artificial Intelligence *Interleaf Desktop Publishing
III. SERVICES
HOW TO MINIMIZE WORKSTATION COST OF OWNERSHIP
*Hardware - Digital's "Plan A and Plan B" Support
*Software - Digital's Education Software Library
*****************************************************************************
To Pre-register, call Mary Mancini at (408) 748-4418. Registration is also
available the day of the Show.
-------
-------
========================================================================
Received: from Sierra.Stanford.EDU by decwrl.dec.com (5.54.4/4.7.34)
id AA29130; Thu, 24 Mar 88 17:12:12 PST
Received: from LEAR.STANFORD.EDU by Sierra.Stanford.EDU with TCP; Thu 24 Mar 88 17:11:39-PST
Message-Id: <12385002851.301.M.MACHEFSKY@LEAR.STANFORD.EDU>
∂25-Mar-88 0740 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu detection of long cycles in graphs
Received: from polya.stanford.edu by SAIL.Stanford.EDU with TCP; 25 Mar 88 07:40:40 PST
Received: from Sushi.Stanford.EDU by polya.stanford.edu (5.54/inc-1.2)
id AA12998; Fri, 25 Mar 88 07:40:25 PST
Message-Id: <8803251540.AA12998@polya.stanford.edu>
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Fri 25 Mar 88 07:35:48-PST
Received: by lindy.stanford.edu; Fri, 25 Mar 88 07:40:00 PST
Received: by Forsythe.Stanford.EDU; Fri, 25 Mar 88 07:38:45 PST
Received: by BYUADMIN (Mailer X1.25) id 3292; Fri, 25 Mar 88 08:39:16 MST
Date: Fri, 25 Mar 88 09:27:25 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Dan Pehoushek <pehoushe@gang-of-four.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Dan Pehoushek <pehoushe@gang-of-four.stanford.edu>
Subject: detection of long cycles in graphs
To: Local Distribution <aflb.tn@sushi.stanford.edu>
On the April 14 AFLB meeting I will present an algorithm which finds
the minimum weighted Hamiltonian Circuit in a graph, or declares that
none exist. The algorithm is used to describe a class of graphs for
which NP-hard problems are polynomially solvable.
Roughly, a graph in this class (with n vertices) must be separable
into two nearly equal sized subgraphs, with at most O(logN) cuts.
This property must also be true of the two subgraphs. If this
property holds then the algorithm runs in polynomial space, and
therefore, time.
dan pehoushek, pehoushek@gang-of-four
∂25-Mar-88 0938 TAJNAI@Score.Stanford.EDU SOE Reception
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Mar 88 09:38:13 PST
Date: Fri 25 Mar 88 09:04:14-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: SOE Reception
To: faculty@Score.Stanford.EDU, students@Score.Stanford.EDU
Message-ID: <12385179736.22.TAJNAI@Score.Stanford.EDU>
The following invitation was sent by Pam Cook:
........................................................................
I would like to invite you to attend a Student Reception sponsored
by the School's Development Office on March 31 from 4:30 to 5:30
p.m. in Terman Grove.
The purpose of the event is to acquaint students
with the Engineering Fund and the kinds of volunteer activities they
could help us with while students. Bob Eustis and National Chair
Karl Schwarz will be making brief comments and some of our
volunteers will be attending.
All undergrad and grad students in the School are invited and we are
expecting about 75. Currently we are drawing on students active in
engineering groups but we are anxious to involve as many students as
possible.
Please let me know if you will be able to attend. Also, please feel
free to invite students or faculty you think would enjoy being
there.
Pam Cook
Director, Engineering Fund, Terman 209, ct.pac@forsythe, 5-1584
............................................
Let me know if you can attend and I'll rsvp.
Carolyn Tajnai
-------
∂25-Mar-88 1006 @Score.Stanford.EDU:MPS@SAIL.Stanford.EDU CS254
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Mar 88 10:05:59 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 25 Mar 88 09:42:23-PST
Date: 25 Mar 88 0946 PST
From: Pat Simmons <MPS@SAIL.Stanford.EDU>
Subject: CS254
To: faculty@SCORE.Stanford.EDU
CS254, ``Automata, Language, and Computability'', is an alternative to
CS154, ``Introduction to Automata and Complexity Theory'', not a sequel.
CS154 presumably is less deductive and more descriptive. I plan to use in
CS254 an approach I call device-based automata theory, where each machine
is a programmable collection of input, output, memory, and control
devices, including stacks, counters, tapes, and queues, and where machines
may be connected serially as if by UNIX pipes. I have proofs of the
generalized pumping theorem (Ogden's lemma) for context free languages,
inherent ambiguity, Greibach's theorem, closure of deterministic CFLs
under complementation, the undecidability results for CFLs, Earley's
algorithm, and other results, that are much more economical than the
traditional proofs.
I define in a general way the notion of one machine simulating another,
using commuting diagrams. The definition is simple enough to be a
feasible framework for showing the hierarchy of machine capabilities, and
for exhibiting canonical forms for machines.
I plan to accommodate students who need to cover the theory of
NP-completeness.
Advisors may want to suggest CS254 to students strong in mathematics, or
who plan to specialize in processing of natural or programming languages.
RW Floyd
∂25-Mar-88 1217 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu minilabs (aka "science centers")
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Mar 88 12:17:08 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 25 Mar 88 12:12:04-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA12224; Fri, 25 Mar 88 12:15:27 PST
Date: Fri, 25 Mar 88 12:15:27 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8803252015.AA12224@Tenaya.stanford.edu>
To: ac@score
Cc: gibbons@sierra
Subject: minilabs (aka "science centers")
Some time ago I sent around a description of an idea to have
industrial "minilabs" in the exedra buildings. Several of you gave me
some excellent suggestions about how to improve the idea, and these
suggestions plus additional thinking have resulted in the following
"concept paper." Jim Gibbons and I would be most interested to hear
any reactions you might have. In particular, are their circumstances
under which you would be interested in being one of the "faculty PIs?"
Although the concept paper below doesn't mention it explicitly, we
have in mind that of the $500,000 annual "research gift" for each
science center, $300,000 annually would be available for the faculty
PI to use to support his or her own research and PhD students.
Jim Gibbons and I will be presenting the science center idea to the
Committee on Research late Monday afternoon, March 28. Any comments that
you might be able to get to us before that time would be most helpful.
(Please cc Gibbons@sierra).
Thanks,
-Nils
----
STANFORD CONFIDENTIAL
SCIENCE CENTERS IN THE EXEDRA
March 25, 1988
This note describes a proposal to invite industrial research
participation in the new Information Sciences buildings (the Exedra).
The idea is to invite each of, say, five companies to send, say, five
researchers to participate with faculty and students in mutually
agreeable research projects. Each participating company would make a
gift to Stanford that would help finance construction of the Exedra
buildings and contribute to the research of participating faculty and
students. Each combination of company researchers, faculty, and
students organized around a central research project theme will
hereinafter be called a "science center."
Although precise details remain to be worked out, we propose the
following general ground rules:
1) Each science center would be led by a Stanford faculty member as
the Principal Investigator. The establishment of a science center
will depend on being able to find an appropriate and eager faculty
P.I. The "project" to be undertaken in the science center would be
one on which the faculty member would be wanting to work on anyway and
one for which s/he would typically be receiving research support. The
project would be mutually agreed on by the faculty P.I. and by a
person proposed by the company as a senior visiting research scholar.
2) All industrial visiting scholars in a science center would have to
be approved by the faculty P.I. Typically, the industrial
participants would be of the same high calibre as any other visitors,
post-docs, or research associates associated with Stanford faculty.
3) Science Center companies would pay the salaries of their own employees
(including any of their own support staff). They would also pay for
(and/or provide) any computer or other equipment which they would use
in the science center.
4) The usual Stanford rules regarding rights, inventions,
publications, etc. would apply to all work done in the science
centers. In particular, the results of the research performed in the
science centers will not be proprietary and will be publishable.
5) Each science center would entail an incremental 2,000 net square
feet of space beyond what would otherwise ordinarily be required for
the participating faculty, their staff, students, and equipment. This
2,000 net square feet is what is estimated to be required by the
participating company researchers, their own staff, and equipment. We
are planning space for five such science centers in the Exedra
buildings.
6) The minimum term for a science center agreement would be five years
with the possibility of renewal.
7) The financial details of each five-person science center are as follows:
Item Base Amount Incremental gift per person
per year above five
Entry Gift $500,000
Research Gift 500,000 $100,000
Totals: $1,000,000 $100,000
The annual Entry Gift would be used as a contribution to the Exedra
building fund. The Research Gift would be used to facilitate interaction
with the company visiting scholars and by the faculty P.I. to support
faculty and student research as part of the science center project.
The following additional issues still need to be addressed:
1) Should the Department or the School of Engineering set up
any kind of management structure to administer the science centers?
It is possible that each could be dealt with as simple extensions
of a faculty member's existing research administration arrangements.
2) How will we deal with the possibility of having more companies
wanting to participate in science centers than we have room for? Probably
we can announce the idea and then accept the first five companies
who subscribe and who are acceptable to prospective faculty P.I.s.
3) Should the science centers continue into the indefinite future or
should they be a temporary phenomenon of five or ten years?
If science centers renew, should they be required to pay the annual
$500,000 entry fee during a subsequent five years?
4) How will we "market" the science center idea among companies? Should
it be tied to the Centennial Campaign and/or to a special
"Exedra Campaign"?
5) Suppose a company doesn't want to wait until the Exedra are
finished before starting a science center. Should we try an "experimental"
science center or two (assuming the availability of space somewhere)? What
gift amounts would be appropriate for such early science centers?
6) Suppose a company wants to participate in a science center working
on a subject not involving the information sciences and not
appropriate to being housed in the Exedra buildings. Would the
University want to extend the science center idea to other areas?
∂25-Mar-88 1304 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu irreducible polynomials
Received: from polya.stanford.edu by SAIL.Stanford.EDU with TCP; 25 Mar 88 13:04:36 PST
Received: from Sushi.Stanford.EDU by polya.stanford.edu (5.54/inc-1.2)
id AA22621; Fri, 25 Mar 88 13:04:26 PST
Message-Id: <8803252104.AA22621@polya.stanford.edu>
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Fri 25 Mar 88 12:59:37-PST
Received: by lindy.stanford.edu; Fri, 25 Mar 88 13:03:37 PST
Received: by Forsythe.Stanford.EDU; Fri, 25 Mar 88 13:02:43 PST
Received: by BYUADMIN (Mailer X1.25) id 9464; Fri, 25 Mar 88 14:02:49 MST
Date: Fri, 25 Mar 88 14:50:02 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Victor Shoup <shoup%CS.WISC.EDU@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Victor Shoup <shoup%CS.WISC.EDU@forsythe.stanford.edu>
Subject: irreducible polynomials
To: Local Distribution <aflb.tn@sushi.stanford.edu>
I'd like to know if the following is an open question.
Given a prime p and a positive integer n,
can we find an irreducible polynomial over GF(p) of degree n
deterministically in time bounded by a polynomial in n and p
(as opposed to log p)?
I don't want to assume any unproved hypotheses, such as the ERH.
-- Victor Shoup
∂25-Mar-88 1316 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Cycle detection
Received: from polya.stanford.edu by SAIL.Stanford.EDU with TCP; 25 Mar 88 13:16:27 PST
Received: from Sushi.Stanford.EDU by polya.stanford.edu (5.54/inc-1.2)
id AA22776; Fri, 25 Mar 88 13:16:12 PST
Message-Id: <8803252116.AA22776@polya.stanford.edu>
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Fri 25 Mar 88 13:11:15-PST
Received: by lindy.stanford.edu; Fri, 25 Mar 88 13:15:13 PST
Received: by Forsythe.Stanford.EDU; Fri, 25 Mar 88 13:10:56 PST
Received: by BYUADMIN (Mailer X1.25) id 9595; Fri, 25 Mar 88 14:10:39 MST
Date: Fri, 25 Mar 88 14:53:36 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
fulk%CS.ROCHESTER.EDU@forsythe.stanford.edu
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: fulk%CS.ROCHESTER.EDU@forsythe.stanford.edu
Subject: Cycle detection
To: Local Distribution <aflb.tn@sushi.stanford.edu>
There is a simple way to find a cycle: do a depth-first search of the
graph, looking for a back edge. A back edge is an edge from the current
node to a node still on the stack. (in other words, mark a node when
you first arrive at it, and unmark it when you leave it. If you find an
edge from the current node to a marked node, you have found a cycle.)
Space requirements: O(# nodes) (beyond the graph). Time requirement:
O(# edges), worst case. Reports a cycle as soon as it has followed
every edge in the cycle. That the search is depth first is crucial;
depth-first order guarantees the existence of a back edge in every
cycle.
Mark Fulk
∂25-Mar-88 1320 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu FA,PDA,Turing machines
Received: from polya.stanford.edu by SAIL.Stanford.EDU with TCP; 25 Mar 88 13:20:23 PST
Received: from Sushi.Stanford.EDU by polya.stanford.edu (5.54/inc-1.2)
id AA22862; Fri, 25 Mar 88 13:19:28 PST
Message-Id: <8803252119.AA22862@polya.stanford.edu>
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Fri 25 Mar 88 13:14:48-PST
Received: by lindy.stanford.edu; Fri, 25 Mar 88 13:18:42 PST
Received: by Forsythe.Stanford.EDU; Fri, 25 Mar 88 13:17:35 PST
Received: by BYUADMIN (Mailer X1.25) id 9764; Fri, 25 Mar 88 14:17:47 MST
Date: Fri, 25 Mar 88 14:57:03 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Anil Nair <alice!nair%ucbvax.berkeley.edu@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Anil Nair <alice!nair%ucbvax.berkeley.edu@forsythe.stanford.edu>
Subject: FA,PDA,Turing machines
To: Local Distribution <aflb.tn@sushi.stanford.edu>
What is it that gives the FA, the PDA and Turing
machines their respective powers? I am looking
for a simple intutive answer. But should help
me in answering questions about restricted TMs,
or enhanced PDAs etc. eg the Write Once Turing
Machine has only the power of a FA while a deterministic
two-stack machine has the full power of a TM.
What do I gain/lose as I go up and down the hierarchy
of these machines. I know all the formal answers and
proofs but still can't get a good intutive feel for it.
Help, anyone?
Anil Nair
∂25-Mar-88 1457 @Sushi.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu 1988 Structure In Complexity Theory Conference
Received: from polya.stanford.edu by SAIL.Stanford.EDU with TCP; 25 Mar 88 14:56:47 PST
Received: from Sushi.Stanford.EDU by polya.stanford.edu (5.54/inc-1.2)
id AA25682; Fri, 25 Mar 88 14:56:45 PST
Message-Id: <8803252256.AA25682@polya.stanford.edu>
Received: from lindy.stanford.edu by Sushi.Stanford.EDU with TCP; Fri 25 Mar 88 14:52:06-PST
Received: by lindy.stanford.edu; Fri, 25 Mar 88 14:55:50 PST
Received: by Forsythe.Stanford.EDU; Fri, 25 Mar 88 14:54:51 PST
Received: by BYUADMIN (Mailer X1.25) id 2353; Fri, 25 Mar 88 15:45:16 MST
Date: Fri, 25 Mar 88 15:01:13 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Stephen R. Mahaney" <srm@research.att.com>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Stephen R. Mahaney" <srm@research.att.com>
Subject: 1988 Structure In Complexity Theory Conference
To: Local Distribution <aflb.tn@sushi.stanford.edu>
Structure In Complexity Theory
Third Annual Conference
Sponsored by the
IEEE Computer Society Technical Committee on
Mathematical Foundations of Computing
and Northeastern University
In cooperation with ACM-SIGACT and EATCS
June 14-17, 1988
Georgetown University
Washington, D.C.
______________________________________________________________________
*** REGISTRATION FORM ***
Return this form by May 23, 1988 with a check in $US made out to "IEEE
Structures Conference" to:
Prof. John C. Cherniavsky
Department of Computer Science
225 Reiss Science Building
Georgetown University
37th and O St., NW
Washington D.C., 20057 USA
Name _________________________________________________________
Affiliation __________________________________________________
Address ______________________________________________________
______________________________________________________________
City _________________________________________________________
State ________________________________________________________
EMail ________________________________________________________
Telephone ____________________________________________________
*** Conference Fees ***
Includes talks, proceedings, breakfasts, lunches, reception and
(except for students) banquet ticket:
By May 23 After May 23
IEEE, ACM, SIGACT
or EATCS member $215 $255
Nonmembers $270 $315
Students $100 $140
Conference Fee $ ______________
Additional banquet tickets at $55:
Number: _____________ $ ______________
Dietary Needs: _______________________________________________
Room Reservations at Georgetown Univ.
1 person/room/night is $45; 2 persons/room/night is $22.50 (tax
included). Specify which nights and if sharing, with whom. ADVANCE
RESERVATION AND PAYMENT IS MANDATORY.
Nights: Mon___ Tue___ Wed___ Thu___ Fri___
If sharing a room, with whom?
______________________________________________________
Total Enclosed: $ ______________
______________________________________________________________________
*** CONFERENCE INFORMATION ***
Location:
The conference will take place on the campus of Georgetown University
in Washington D.C. The campus is located in the Georgetown area at
37th and O St. N.W. On campus housing will be in Village C, a
dormitory used for summer conferences. Check-in time is 4:00 pm.
Each room is air-conditioned, has a private bath and two single beds
and costs $45.00/night/room. We have reserved 80 rooms and early
reservations are mandatory. We have set aside a block of 40 rooms for
those wishing to stay Friday Night. The conference fee includes
breakfast and lunch served in the Village C cafeteria. It offers a
varied menu - including vegetarian; kosher meals will be available.
Refunds can be arranged by contacting John Cherniavsky by May 27,
1988. After May 27, the conference commits payment to the university
for reserved rooms and meals.
For those wishing other accommodations, we have made arrangements with
the State Plaza Hotel near the campus of George Washington University
approximately one mile from Georgetown University. The rates are $67,
$72.50 and $78 for singles, doubles and triples respectively. These
are suites with kitchens and are appropriate for families. The rates
will be honored the weekends before and and after the meeting. The NSF
uses this hotel extensively and has been quite satisfied. The address
is 2117 E Street, N.W.; for reservations call 800-424-2859 and mention
the Georgetown University Structures in Complexity Theory Meeting.
Cabs or buses can be used to get from the hotel to Georgetown
University (about a $3.00 cab ride). Other nearby hotels (with higher
rates) are the Georgetown Marbury Hotel (3000 M St.; 202-726-500), The
Georgetown Inn (1310 Wisconsin Ave.; 202-333-8900) and the Four
Seasons Hotel (2800 Pennsylvania Ave.; 800-268-6282).
Activities in the Nations Capitol:
Washington is a delightful city with many free museums and other
attractions such as theater and dance performances. The Georgetown
area offers excellent restaurants, entertainment venues, and shopping
- all within a walk of the University. Most of the memorials are open
until 9:00 pm. during the summer. This is especially welcome since
temperatures in the 90's are not uncommon during June. Recommended
are the Smithsonian museums (especially the Air and Space museum and
the new African museum), the various art galleries (the Corcoran is
very nice), and the Vietnam memorial. The Smithsonian complex is
served by the Metro rail system. The nearest station, unfortunately,
is near the George Washington University campus. Cab rides are
inexpensive.
June temperatures average daily highs of 85 F. and lows of 65 F. Rain
is possible.
Reception and Registration:
On Monday Evening at 8:00 there will be a wine and cheese reception in
the Galleria of the Intercultural Center (ground level entrance from
the main campus). Registration will be set up in the Intercultural
Center on Monday evening and will be set up adjacent to the lecture
hall during the remainder of the conference.
Banquet and Retrospective Talks
in Honor of Juris Hartmanis
On Wednesday evening we are planning a banquet to honor Juris
Hartmanis on the occasion of his 60th birthday for his many
contributions to Computer Science; particularly his contributions to
the topics of this conference. Juris Hartmanis is the founder of
computational complexity. Indeed the field took its name from a
seminal paper coauthored by Hartmanis and Stearns in 1965 "On the
Computational Complexity of Algorithms." His subsequent work,
reported in over 60 papers, introduced many of the major concepts and
issues. One can easily discern the influence and research
contributions made by Hartmanis and his collaborators.
The banquet will be held in the historic Madison house located at 2017
Eye Street, N.W. (just off Pennsylvania Avenue and four blocks from
the current White House). This was the personal residence of our 4th
President and the official "White House" while the current White House
was being rebuilt after the War of 1812. The banquet will be prepared
by Franklin King who has worked as chef in a number of Washington's
best restaurants and now manages all functions at the Madison house.
The banquet will be preceded by a cocktail hour. Special dietary
arrangements may be requested at registration. Transportation will be
provided. It is strongly suggested that proper attire be worn
(jackets and ties for men). An example of inappropriate dress would
be blue jeans or a T-shirt. To purchase banquet tickets only, mail
the registration form to John Cherniavsky by June 1, 1988. The cost
is $55 and John promises it will be well worth it!
The Wednesday afternoon session, prior to the banquet, will be three
invited talks that provide a retrospective of Juris Hartmanis'
research contributions and influence. Speakers are Richard Stearns,
Allan Borodin and Paul Young.
*** Transportation ***
Georgetown University is located approximately 20 miles from Dulles
International Airport, 5 miles from Washington National Airport, 5
miles from Union Railway Station, and 35 miles from Baltimore-
Washington International Airport. A cab ride from Dulles will cost
about $25.00 - $30.00, from Washington National about $8.00 - $10.00,
and from Union Station about $5.00.
Driving from Dulles Airport
Take Route 66 until you see the Key Bridge exit. Cross the Key Bridge,
take a right on M street, and a left at the second stop light (33rd
Street). Take your first left (Prospect Street) and follow it until
you come to the entrance of the Georgetown University Parking lot.
Pay for your parking and keep your receipt (parking permits will be
made available for reduced rate parking). Village C is behind the
large dormitory that overlooks the parking lot.
Driving from National Airport
Go North on the George Washington Parkway and take the exit to
Rosslyn. Take a right and you will come to Key Bridge. Proceed as
above.
Other Driving Routes
>From I-95 South, take the Beltway (I-495) North. Follow it around
until you see the exit for the Cabin John Parkway. If the time is
before 3:15 PM or after 6:30 PM, take this exit and proceed into
Washington D.C. This turns into the George Washington Parkway
(Maryland) and then to Canal Road which turns into M Street at the Key
Bridge. Proceed as above. If the time is wrong or you cross the
American Legion Bridge on the Beltway (over the Potomac river) proceed
to Route 66 and follow the above directions.
Local Arrangements
Contact John Cherniavsky at 202-687-5874. During the conference
202-687-2666 reaches Village C for emergency messages.
*** TECHNICAL PROGRAM ***
Monday, June 13, 1988
8:00 pm. Reception: Galleria of the Intercultural Center
Tuesday, June 14, 1988
Morning Session, Chair: Timothy Long
9:00-10:00 U. Schoening, EWH Koblenz: The Power of Counting.
10:00-10:40 S. Tang and O. Watanabe, University of California, Santa
Barbara: On Tally Relativizations of BP-Complexity Classes.
11:10-11:50 B. Halstenberg and R. Reischuk, Technische Hochschule
Darmstadt: Relations Between Communication Complexity Classes.
11:50-12:30 R. Impagliazzo and M. Naor, University of California,
Berkeley: Decision Trees and Downward Closures.
Afternoon Session, Chair: Richard Ladner
2:00-2:40 J. Balcazar, Barcelona: Logspace Self-Reducibility.
2:40-3:20 D. Barrington, University of Massachusetts; N. Immerman,
Yale University and H. Straubing, Boston College: On Uniformity Within
NC~1.
3:50-4:30 L. Pitt, University of Illinois and M. Warmuth,
University of California, Santa Cruz: Reductions Among Prediction
Problems: On the Difficulty of Predicting Automata.
4:30-5:10 O. Ibarra and T. Jiang, University of Minnesota: Trading
Reversals for Alternation.
Wednesday, June 15, 1988
Morning Session, Chair: Alan Selman
9:00-10:00 M. Li, Harvard University and P. Vitanyi, Universiteit
van Amsterdam: Two Decades of Applied Kolmogorov Complexity.
10:00-10:40 E. Allender, Rutgers University and O. Watanabe,
University of California, Santa Barbara: Kolmogorov Complexity and
Degrees of Tally Sets.
11:10-11:50 N. Immerman, Yale University: Nondeterministic Space is
Closed Under Complementation.
11:50-12:30 A. Borodin, S. Cook, University of Toronto; W. Ruzzo,
University of Washington and M. Tompa, IBM Research Center; Two
Applications of Complementation via Inductive Counting.
Invited Session of Retrospective Talks
Afternoon Session, Chair: Ronald Book
2:00-2:45 Richard Stearns, SUNY at Albany: Hartmanis: The Beginning
of Computational Complexity.
2:45-3:30 Allan Borodin, University of Toronto: Hartmanis: The
Development of a Field; The Development of a Department.
4:00-4:45 Paul Young, University of Washington: Hartmanis: The
Isomorphism Conjecture.
Banquet at the Madison House
6:00 pm. Buses leave Village C parking lot beginning at 5:45 pm.
Meal seating at 7:00 pm.
Thursday, June 16, 1988
Morning Session, Chair: Uwe Schoening
9:00-9:40 L. Fortnow, J. Rompel and M. Sipser, MIT: On the Power of
Multi-Prover Interactive Protocols.
9:40-10:20 A. Condon, University of Wisconsin: Space Bounded
Probabilistic Games.
10:50-11:30 J. Lutz, Iowa State University: Pseudorandom Sources for
BPP.
11:30-12:10 K. Ko, SUNY at Stony Brook: Distinguishing Reducibilities
by Sparse Sets.
Afternoon Session, Chair: Klaus Wagner
2:00-2:40 J. Cai, Yale University and L. Hemachandra, Columbia
University: Enumerative Counting is Hard.
2:40-3:20 D. Huynh, University of Texas: The Complexity of Ranking.
3:50-4:30 J. Toran, Barcelona: An Oracle Characterization of the
Counting Hierarchy.
4:30-5:10 S. Buss, University of California, Berkeley and L. Hay,
University of Illinois: On Truth-Table Reducibility to SAT and the
Difference Hierarchy over NP.
8:00pm Business Meeting
Friday, June 17, 1988
Morning Session, Chair: James Royer
9:00-10:00 R. Book, D.-Z. Du and D. Russo, University of California,
Santa Barbara: On Polynomial and Generalized Complexity Cores.
10:30-11:10 K. Ko, SUNY at Stony Brook: Relativized Polynomial Time
Hierarchies Having Exactly K Levels.
11:10-11:50 J. Shinoda and T. Slaman, Harvard University: On The
Theory of Polynomial Degrees of the Recursive Sets.
Afternoon Session, Chair: Juris Hartmanis
2:00-3:00 K. Wagner, Universitat Augsburg: Bounded Query
Computations.
3:30-4:10 J. Kadin, Cornell University: The Polynomial Hierarchy
Collapses if the Boolean Hierarchy Collapses.
4:10-4:50 L. Longpre, Northeastern University and P. Young,
University of Washington: Cook is Faster than Karp: A Study of
Reducibilities in NP.
----------------------------------------------------------------------
∂25-Mar-88 1617 @Score.Stanford.EDU:pratt%jah@Sun.COM Agenda item for Tuesday: graphics
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Mar 88 16:17:18 PST
Received: from Sun.COM by SCORE.STANFORD.EDU with TCP; Fri 25 Mar 88 16:11:46-PST
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
id AA23511; Fri, 25 Mar 88 16:16:31 PST
Received: from jah.sun.com by snail.sun.com (4.0/SMI-3.2)
id AA20503; Fri, 25 Mar 88 16:16:38 PST
Received: by jah.sun.com (3.2/SMI-3.2)
id AA12863; Fri, 25 Mar 88 16:16:55 PST
Date: Fri, 25 Mar 88 16:16:55 PST
From: pratt%jah@Sun.COM (Vaughan Pratt)
Message-Id: <8803260016.AA12863@jah.sun.com>
To: ac@score.stanford.edu
Subject: Agenda item for Tuesday: graphics
Cc: pratt%jah@Sun.COM
Leo Guibas, Bob Sproull, and I gave a graphics qual to David Salesin
last week, for which he studied hard for two months and passed with
flying colors. We felt that the qual was of a uniformly high quality,
easily up to Stanford's high standards.
It has since been pointed out to us that we are missing a basic
ingredient of a qual, namely department approval. There is also the
question of whether we meet the recently instituted three-faculty
criterion for creating a new qual: although any of Don Knuth, Tom
Binford, or Bob Floyd, if willing, might have made an appropriate third
member, Leo asked Bob Sproull to fill that role because he felt Bob's
combination of prominence in computer graphics and connection to the
department by way of the visiting committee qualified him even better.
While I didn't think to ask about the rationale for this choice at the
time (I plead being an absent minded professor), on being confronted
with the question I have to agree that the visiting committee
connection may be more tenuous than the Ph.D. committee may have
intended when drafting the three-faculty rule.
Our main concern at this point is to avoid David's being penalized for
something that was not his fault. It would be particularly tough on
David to require him to take a second qual.
The most direct solution is for me to propose as an agenda item for
this Tuesday's faculty meeting the motion that the faculty consider
David Salesin to have met the department's qual requirements. I will
speak for this motion at the meeting, but I will also be happy to speak
in this forum to any points raised in advance.
-v
∂25-Mar-88 1636 CHANDLER@Score.Stanford.EDU General Faculty Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Mar 88 16:36:06 PST
Date: Fri 25 Mar 88 16:30:01-PST
From: Joyce R. Chandler <CHANDLER@Score.Stanford.EDU>
Subject: General Faculty Meeting
To: faculty@Score.Stanford.EDU, bureaucrats@Score.Stanford.EDU
Message-ID: <12385260887.20.CHANDLER@Score.Stanford.EDU>
Just a reminder...General faculty meeting to be held Tuesday, 3/29/88
in MJH-146 at 2:15. I must have any suggestions for agenda items
immediately.
Thanks.
-------
∂25-Mar-88 1752 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu fac mtg agenda
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Mar 88 17:52:00 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 25 Mar 88 17:45:51-PST
Received: by Tenaya.stanford.edu (4.0/SMI-DDN)
id AA12443; Fri, 25 Mar 88 17:49:19 PST
Date: Fri, 25 Mar 88 17:49:19 PST
From: nilsson@Tenaya.stanford.edu (Nils Nilsson)
Message-Id: <8803260149.AA12443@Tenaya.stanford.edu>
To: faculty@score
Cc: chandler@score
Subject: fac mtg agenda
Here's the agenda so far for Tuesday's general CSD faculty mtg. Feel
free to add items. -Nils
-----
COMPUTER SCIENCE DEPARTMENT GENERAL FACULTY MEETING
TUESDAY, MARCH 29, 1988
2:15 p.m., Room 146 Margaret Jacks Hall
Agenda
1. Approval of Degree Candidates---Sharon Hemenway
2. Staff Reports
Forum---Carolyn Tajnai
Financial/Administrative---Betty Scott and George Wheaton
CSD-CF---Jim Ball
Educational---Stuart Reges and Roy Jones
(Proposal for a new lecturer)
3. Committee Reports (if any)
4. Student Representative Reports (if any)
5. Plans for CSD Retreat---Nils Nilsson and George Wheaton
6. Proposed Action Regarding Graphics Qual Exam---Vaughan Pratt
7. Faculty Search Committee Reports on Their Progress (if any)
Software Applications---David Cheriton
Architecture---John Hennessy
Programming Languages---Vaughan Pratt
Theory---Jeff Ullman
Asst. Chair for Education Position---George Wheaton
8. Report on New Building Progress---Nils Nilsson and George Wheaton
9. Other